API design is the process of defining the interface between different software components. It involves specifying the endpoints, request/response formats, and the operations that can be performed on the API. It's a common question in system design interviews, especially for junior positions. Typically, you will be asked to design a RESTful API for a given scenario. GraphQL is another popular API design that is growing in popularity but most of the interview questions still focus on RESTful API design.
What is a REST API?
A REST API is a set of rules that developers follow when creating APIs. It relies on standard HTTP methods and uses resource-based URLs to perform operations. The core principles of RESTful APIs include:
- Statelessness: Each request from a client must contain all the information needed to process it, and the server doesn't store any session data.
- Uniform Interface: Resources are accessed in a consistent manner, typically through URIs (Uniform Resource Identifiers).
- Resource-Based Architecture: Everything is considered a resource (e.g., users, posts, comments), and these resources are manipulated using standard HTTP methods.
Examples of RESTful APIs
GET /users: Retrieve a list of users.POST /users: Create a new user.GET /users/{id}: Retrieve a user by ID.PUT /users/{id}: Update a user by ID.DELETE /users/{id}: Delete a user by ID.
Best Practices and the Wrong vs. Right Way of Writing REST APIs
Designing RESTful APIs is mostly straightforward, but there are some common mistakes that you should avoid.
1. Using Verbs in URLs
Wrong Way:
GET /getAllBooks
POST /createNewBook
Right Way:
GET /books
POST /books
In RESTful design, the endpoint URL should represent a resource (a noun), not an action (a verb). The HTTP method already indicates the action to be performed.
Grasping the building blocks ("the lego pieces")
This part of the guide will focus on the various components that are often used to construct a system (the building blocks), and the design templates that provide a framework for structuring these blocks.
Core Building blocks
At the bare minimum you should know the core building blocks of system design
- Scaling stateless services with load balancing
- Scaling database reads with replication and caching
- Scaling database writes with partition (aka sharding)
- Scaling data flow with message queues
System Design Template
With these building blocks, you will be able to apply our template to solve many system design problems. We will dive into the details in the Design Template section. Here’s a sneak peak:
Additional Building Blocks
Additionally, you will want to understand these concepts
- Processing large amount of data (aka “big data”) with batch and stream processing
- Particularly useful for solving data-intensive problems such as designing an analytics app
- Achieving consistency across services using distribution transaction or event sourcing
- Particularly useful for solving problems that require strict transactions such as designing financial apps
- Full text search: full-text index
- Storing data for the long term: data warehousing
On top of these, there are ad hoc knowledge you would want to know tailored to certain problems. For example, geohashing for designing location-based services like Yelp or Uber, operational transform to solve problems like designing Google Doc. You can learn these these on a case-by-case basis. System design interviews are supposed to test your general design skills and not specific knowledge.
Working through problems and building solutions using the building blocks
Finally, we have a series of practical problems for you to work through. You can find the problem in /problems. This hands-on practice will not only help you apply the principles learned but will also enhance your understanding of how to use the building blocks to construct effective solutions. The list of questions grow. We are actively adding more questions to the list.
