REST API
REST (Representational State Transfer) is an architectural style for designing APIs on top of HTTP, the foundation of the web. Each resource is identified by a unique URI, and HTTP methods such as GET, POST, PUT, and DELETE express the operation to be performed on that resource. The server follows a stateless principle, retaining no client state between requests, and responses may include links to related resources. JSON has become the de facto standard response format, and HTTP status codes distinguish success from failure. The fact that REST can be accessed from anywhere -- browsers, curl, mobile apps -- without any separate protocol or tooling is the background for its wide adoption.
βΆArchitecture Diagram
π RelationshipDashed line animations indicate the flow direction of data or requests
When a team needs a way to request or modify data on a server, letting every team define URL structures and request formats independently leads to confusion quickly. One API uses /getUser?id=1 for lookup, another sends an ID as a POST to /user/fetch, and yet another uses a completely different path like /api/v2/user-info. Every time the team grows or the API is opened to external developers, someone has to explain individually 'which method to use for this URL' and 'what the response format is', and the moment documentation falls even slightly out of date, it diverges from actual behavior. When the only client was a single web browser this could be muddled through, but once mobile apps and third-party integrations are added, API maintenance becomes rapidly unmanageable without consistent rules.
When Roy Fielding proposed REST in his doctoral dissertation in 2000, the dominant style for web APIs was SOAP. SOAP required a strict XML message envelope format and WSDL definition files, and even a simple data lookup required hundreds of lines of XML back and forth. This strictness was an advantage in enterprise system integration, but as the web and mobile exploded in growth, demand grew for 'build fast, integrate fast'. Because REST proposed reusing the HTTP methods, URIs, and status codes that the web was already using, the API could be tested with a single curl command without any separate specification language or tooling. When Twitter, GitHub, Stripe, and others released REST APIs in the late 2000s, it became the de facto standard for web APIs, and as JSON replaced XML the advantages of lightness became even more pronounced.
The core of a REST API is 'resource-centered thinking'. Define resources first, not operations, and express actions on those resources using HTTP methods. For handling a list of users, the URL is /users: GET to retrieve the list, POST to create a new user. A specific user is /users/123: GET for detailed retrieval, PUT or PATCH to update, DELETE to remove. This is why URLs use nouns rather than verbs. When a client sends a request, the server returns the current representation of that resource in a format like JSON and communicates the result via HTTP status codes. 200 means success, 201 means something was created, 404 means the resource was not found, 422 means the request format is correct but the content is invalid. The status code alone reveals how the request was processed, allowing branching logic before parsing the response body. The stateless principle is also important. Because the server does not remember previous requests, each request must include the authentication token and any other necessary context. This means that when the server is scaled horizontally, there is no need to worry about session synchronization.
Use methods to separate resource actions
app.get("/users/:id", (req, res) => {
res.json({ id: req.params.id });
});
app.post("/users", (req, res) => {
res.status(201).json({ id: "123" });
});Reading the same /users path with different methods shows the REST idea clearly: GET means read, POST means create.
Status codes communicate the result briefly
if (!user) {
return res.status(404).json({ message: "not found" });
}
return res.status(200).json(user);Even before the body is parsed, 404 and 200 tell you whether the resource exists and whether the request succeeded.
REST and GraphQL are alike in that both are API layers through which a client retrieves server data. But their approaches differ. REST divides endpoints by resource and the server determines the response structure. GraphQL uses a single endpoint where the client specifies the fields it needs in a query. REST is stronger when the resource structure is stable and the variety of clients is relatively uniform. The API intent is apparent from just the URL and HTTP method, and HTTP-level caching works naturally. On the other hand, when the data combination needed differs significantly per screen, or when multiple resources must be fetched together for a single screen, REST may require multiple requests or return fields the client does not need. If you are operating a public API or need to fully leverage standard HTTP infrastructure (CDN caching, load balancers, etc.), REST is advantageous. If complex frontend requirements need to drive data fetching, it is worth examining GraphQL.
Commonly Compared Concepts
GraphQL
An API query language through which clients precisely request the data they need
REST divides endpoints by resource and the server determines the response structure, while GraphQL uses a single endpoint where the client specifies the fields it needs.
WebSocket
A real-time channel that keeps a connection open after HTTP and exchanges messages in both directions
REST is a request-response model where each interaction starts with a new request, while WebSocket keeps a long-lived connection open so both sides can exchange messages continuously.
Server-Sent Events
A one-way realtime stream where the server keeps an HTTP response open and pushes events
REST ends each response when the request is done, while SSE keeps one HTTP response open and continues streaming server events. The deciding factor is whether a realtime stream is needed.
REST APIs are the most universal way to expose server-managed resources to multiple clients. For services centered on CRUD patterns -- user management, product catalogs, order processing -- resources and endpoints map one-to-one, making design intuitive. REST is also the natural choice when opening an API to external developers. It can be called from any language or platform that supports HTTP, and the URL structure alone reveals which resource is being handled, keeping the entry barrier low. Writing an OpenAPI (Swagger) specification enables automated documentation generation and client code generation. REST is also frequently used for HTTP communication between services in a microservice environment. As the number of services grows and call chains lengthen, it becomes common to place an API gateway in front to centrally manage authentication, rate limiting, and routing. There are also cautions. In complex frontends that need to combine multiple resources for a single screen, several REST calls back and forth can accumulate latency. When resource boundaries do not align well with UI requirements, it may be necessary to introduce a BFF (Backend For Frontend) pattern or revisit the API design.