A survival kit to beat APIs interview.

11 questions you need to know how to answer.

Jan 09, 2025

If you are looking for a backend or full-stack position, there’s a 99% chance they will ask you questions about building APIs.

REST APIs have become a cornerstone of modern software development, and understanding them is essential for acing any interview in this domain.

Here is a carefully curated list of questions you need to know, along with explanations, to help you stand out.

Practice makes perfect, and there’s no better way to get ready for interviews than by building the tools you use daily. CodeCrafters lets you create your own Docker, Git, Redis, and more.
Hands-on Projects + Practice = Job Offer
Sign up and get 40% off if you upgrade.
Thank you to our sponsors who keep this newsletter free!

Start Building Today!

1. Can You Explain CRUD Operations in the Context of REST?

CRUD (Create, Read, Update, Delete) operations are fundamental to REST API design and map directly to HTTP methods:

POST: Create a new resource.
GET: Read or retrieve a resource.
PUT: Update an entire resource.
PATCH: Partially update a resource.
DELETE: Remove a resource.

There are 4 more you should know (just in case you found a picky interviewer).

HEAD: Retrieve headers for a resource without the response body.
OPTIONS: Discover the allowed methods and communication options for a resource.
TRACE: Echo back the request for debugging purposes.
CONNECT: Establish a tunnel to the server, typically for SSL/TLS through a proxy.

2. What Is the Difference Between PUT and PATCH?

PUT replaces the entire resource. For instance, updating a user profile with PUT requires sending the full user object, even if only the email is changed.
PATCH allows partial updates, making it more efficient for specific field modifications.

For example, setting OrderStatus to “Shipped” should use PATCH, not PUT, because it’s a partial update.

Knowing when to use each method demonstrates your ability to design efficient APIs.

3. What Are Common HTTP Status Codes, and What Do They Mean?

There are hundreds of HTTP status codes, and you can split them into five categories:

Informational (100–199)
Successful (200–299)
Redirection (300–399)
Client Error (400–499)
Server Error (500–599)

But don’t worry, you don’t need to memorize them all. Here are the most common:

200 OK: Successful GET request.
201 Created: Resource created successfully (POST).
204 No Content: DELETE request successful, no response body.
400 Bad Request: Client error due to invalid input.
401 Unauthorized: Authentication required or invalid.
403 Forbidden: User lacks access rights.
404 Not Found: Resource does not exist.
409 Conflict: The request could not be completed due to a conflict with the current resource state.

5xx Internal Server Error: The server encountered an error.

4. What Does It Mean for a REST API to Be Stateless?

Statelessness ensures that each API request contains all the information needed to process it. Servers do not store client state between requests, which:

Simplifies server design.
Improves scalability.

Authentication tokens, for example, are included in each request rather than stored server-side.

5. How Do You Secure a REST API?

Security is a priority for any API. Key techniques include:

Authentication and Authorization: You can use API keys, OAuth, and JWT (JSON Web Tokens) to control resource access.
Rate Limiting: Prevent abuse by restricting the number of requests a client can make within a given time frame.
Input Validation: Protect against common vulnerabilities like SQL injection and XSS by validating all user inputs.
HTTPS: Always encrypt data in transit using SSL/TLS to secure communication between clients and servers.
Encryption at Rest: Encrypt sensitive data stored on the server (e.g., databases and logs) to protect against unauthorized access or breaches.

Discussing these practices shows you understand API security concerns.

6. How Do You Version a REST API?

APIs evolve, and versioning ensures backward compatibility:

URL Versioning: Include the version in the URL (e.g., /api/v1/resource or /api/resource?api-version=1).
Custom Headers: Use headers like Accept: application/vnd.company.v2+json.

Top reasons for versioning APIs:

API Evolution with backward compatibility: As your API evolves, versioning allows you to introduce new features, deprecate outdated functionality, and improve without disrupting existing Consumers.
Consumer flexibility: Different Consumers may need different requirements or specific features in a particular API version.

Versioning strategies help manage transitions for consumers of your API.

It is important to mention that introducing different versions of APIs will add complexity to API management. You’ll need to plan carefully to retire old versions smoothly and keep clients updated about changes.

7. What Is Pagination, and How Is It Implemented in REST APIs?

Pagination manages large datasets by splitting them into smaller chunks. It improves scalability and response times.

Limit-Offset Pagination

This method uses two parameters:

limit: Specifies the number of items per page
offset: Indicates the starting position

GET /items?limit=10&offset=20

This request retrieves 10 items starting from the 21st item.

Cursor-Based Pagination

This method uses a cursor (often an encoded string) to keep track of the current position.

GET /items?cursor=eyJpZCI6MjB9

Page Number Pagination

This approach uses page numbers and page size.

GET /items?page=3&size=10

This retrieves the 3rd page with 10 items per page.

Keyset Pagination

This method uses a unique key (e.g., ID or timestamp) to fetch the next set of items.

GET /items?after=1627938391&limit=10

8. Can You Discuss Rate Limits and Their Importance?

Rate limiting controls the number of API calls a client can make within a specific time frame. It is essential for:

Preventing Abuse: Stops malicious or excessive use of the API that could overwhelm the system.
Managing Resource Allocation: Ensures server resources are shared fairly among all clients.
Ensuring Fair Usage: Protects against a single client monopolizing API capacity.

Rate Limiting Algorithms

Several algorithms can be used to implement rate-limiting:

Fixed Window Counter: Simple but can lead to uneven traffic distribution.
Sliding Log: Offers precise control but may be resource-intensive.
Sliding Window Counter: Balances precision and efficiency.
Token Bucket: Allows for traffic bursts while maintaining a long-term rate limit.

9. What Is Idempotency, and Why Is It Important?

Idempotency ensures that multiple identical requests have the same effect as a single request. For example:

GET, DELETE, PUT, HEAD, OPTIONS, and TRACE are idempotent.
POST is indeed not idempotent.

While PATCH is sometimes considered non-idempotent, its idempotency depends on the implementation.

Idempotency is crucial in distributed systems to handle retries without unintended side effects.

The importance of idempotency extends beyond just handling retries in distributed systems:

Reliability in Distributed Systems: Idempotency allows for safe retries in case of network failures or timeouts, ensuring consistency across distributed components.
Data Consistency: It prevents unintended side effects from duplicate requests, maintaining data integrity.
Simplified Error Handling: Clients can safely resend requests without worrying about adverse effects, simplifying error handling logic.
Fault Tolerance: Idempotent operations improve system resilience by allowing automatic retries in case of failures.
Concurrency Control: In multi-user environments, idempotency helps minimize conflicts and provides more robust concurrency control.
Predictability: Systems built with idempotent operations are often more predictable, simplifying testing and maintenance.

In conclusion, idempotency is a fundamental concept in designing reliable and scalable distributed systems, especially in the context of RESTful APIs and microservices architectures.

It provides a safety net against the uncertainties of network communications and helps maintain data consistency in complex, distributed environments.

10. How Can You Improve API Performance?

Caching is one of the best strategies for improving API performance:

Client-Side Caching: Use headers like Cache-Control and ETag to reduce redundant requests.
Server-Side Caching: Cache frequently accessed data in-memory with tools like Redis or Memcached.
CDN Caching: Distribute cached content geographically to reduce latency.
Distributed Caching: Store data across multiple nodes for improved scalability and fault tolerance.
Database Query Result Caching: This reduces the load on the database and improves response times.
Database Query Optimization: Focus on optimizing database queries through proper indexing, query analysis, and efficient join operations. Sometimes, a lot of performance gets wasted at the persistence layer.
Connection Pooling: Reuse database or HTTP connections to avoid the overhead of establishing new connections repeatedly.
Efficient Data Serialization: You can consider binary formats like Protocol Buffers for faster serialization and deserialization.
Content Compression: Use HTTP compression (e.g., Gzip or Brotli) to reduce payload size, improving response times for large responses.

Improving API performance is about finding what works best for your system. Use smart caching, reduce extra overhead, and keep things simple where you can.

These tweaks can make your APIs faster and ready to handle more traffic without breaking a sweat.

11. How Do You Document REST APIs?

Documentation is critical for API usability and adoption. Best practices include:

Use OpenAPI (Swagger) to create interactive documentation.
Include:
- Endpoint descriptions.
- Request/response examples.
- Query parameters, headers, and error codes.

Well-documented APIs save time and, more importantly, reduce friction for developers.