0% found this document useful (0 votes)
5 views

REST_Interview_Problems

The document outlines key principles of REST, including statelessness, client-server separation, and resource-based design, which influence API design by promoting clear URIs and standard HTTP methods. It discusses versioning strategies for public REST APIs, emphasizing backward compatibility and best practices. Additionally, it covers handling partial updates, the significance of safe and idempotent HTTP methods, and security measures for REST APIs, including authentication, authorization, and input validation.

Uploaded by

pbecic
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

REST_Interview_Problems

The document outlines key principles of REST, including statelessness, client-server separation, and resource-based design, which influence API design by promoting clear URIs and standard HTTP methods. It discusses versioning strategies for public REST APIs, emphasizing backward compatibility and best practices. Additionally, it covers handling partial updates, the significance of safe and idempotent HTTP methods, and security measures for REST APIs, including authentication, authorization, and input validation.

Uploaded by

pbecic
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

REST for Strong Senior Developers

What are the key principles of REST and how do they influence API design?
 REST (Representational State Transfer) is based on architectural principles for building
scalable web services.
 Key principles:
 Stateless — each request contains all context needed for processing.
 Client-Server — separation of concerns improves scalability and flexibility.
 Uniform Interface — consistent use of HTTP methods (GET, POST, PUT, DELETE, etc.).
 Resource-Based — everything is treated as a resource identified by a URI.
 Cacheable — responses should indicate cacheability to improve performance.
 Layered System — allows intermediaries (proxies, load balancers).
 Influence on design:
 Clear, consistent resource URIs (e.g., /users/123).
 Use of standard HTTP methods and status codes.

How would you design a versioning strategy for a public REST API?
 Versioning ensures backward compatibility as APIs evolve.
 Common strategies:
 URI versioning (e.g., /v1/users).
 Header versioning (e.g., Accept: application/vnd.api.v2+json).
 Query param versioning (e.g., ?version=2).
 Best practices:
 Avoid breaking existing clients.
 Document deprecated versions and support timelines.
 Use semantic versioning if maintaining multiple major versions.

How do you handle partial updates in REST APIs?


 Use the HTTP PATCH method to apply partial updates.
 PATCH applies changes to a resource without replacing the entire resource (unlike
PUT).
 Formats:
 JSON Merge Patch — simpler, supported by many APIs.
 JSON Patch — supports operations like add, remove, replace (RFC 6902).
 Validation:
 Ensure patch operations are validated against schema or business rules.
 Return appropriate status codes (e.g., 400 for invalid patch).

What are idempotent and safe HTTP methods and why do they matter?
 Safe methods:
 Do not modify server state (e.g., GET, HEAD).
 Idempotent methods:
 Multiple identical requests produce the same result (e.g., PUT, DELETE).
 Importance:
 Helps clients (e.g., retries) and intermediaries (e.g., caches, proxies) behave predictably.
 Improves fault tolerance and system resilience.
 POST is neither safe nor idempotent — used for creating new resources or complex
operations.

How do you ensure REST API security for public and internal use cases?
 Security measures include:
 Authentication — OAuth2, JWT, API Keys.
 Authorization — role-based access control (RBAC), scopes.
 Rate limiting — protect from abuse (e.g., using API Gateway or filters).
 Input validation — prevent injection and malformed data.
 HTTPS — always enforce TLS for confidentiality and integrity.
 Additional practices:
 CORS configuration for cross-domain access.
 HATEOAS or OpenAPI for discoverability and self-descriptive APIs.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy