REST

Basic System Design
≈ 2 min read

An HTTP API Around Resources

REST is a common approach to building HTTP APIs where the address describes a resource and the HTTP method describes the action on it. The client works with understandable URIs and standard protocol semantics.

GET /users/42
POST /orders
PUT /users/42/profile
DELETE /sessions/abc123

Such an interface is convenient between backend services, browsers, and mobile applications because HTTP is supported almost everywhere.

The Method and Status Carry Meaning

GET is used for reading, POST for creation or starting an operation, PUT for writing a representation at a known address, and DELETE for removal. The response also carries an HTTP status: for example, 200 means a successful response, 201 means a resource was created, and 404 means the requested resource was not found.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Alice"
}

The URI Should Describe the Domain

An API is easier to read when the path describes an entity instead of repeating the name of an internal method. For example, /orders/15 is more resilient to implementation changes than /callOrderServiceMethod.

The body format is often JSON, but REST does not require it. What matters more is a stable contract and keeping clients independent from storage details or the internal structure of the service.

REST is not just "JSON over HTTP". API quality comes from consistent resource, method, and status semantics together with contract compatibility.