The Runtime Theory
Web Development

REST API Design

Resource-oriented design, HTTP methods and status codes, idempotism, versioning, pagination, and error response patterns.

The Runtime Theory Team1 min read
▸ On this page

REST API Design

REST (Representational State Transfer) is an architectural style for designing web APIs that leverages HTTP's built-in semantics.

Resource-Oriented Design

In REST, every entity is a resource identified by a URL:

plaintext
GET    /api/users          → list all users
GET    /api/users/42       → get user 42
POST   /api/users          → create a new user
PUT    /api/users/42       → replace user 42
PATCH  /api/users/42       → modify user 42
DELETE /api/users/42       → delete user 42

Resources can be nested:

plaintext
GET    /api/users/42/posts → get all posts by user 42
POST   /api/users/42/posts → create a post by user 42

HTTP Methods and Idempotence

MethodIdempotent?Safe?Purpose
GET✅ Yes✅ YesRetrieve a resource
POST❌ No❌ NoCreate a resource or trigger a process
PUT✅ Yes❌ NoReplace a resource entirely
PATCH❌ No❌ NoUpdate part of a resource
DELETE✅ Yes❌ NoDelete a resource
HEAD✅ Yes✅ YesSame as GET but without the body
OPTIONS✅ Yes✅ YesList allowed methods

An idempotent operation means applying it multiple times has the same effect as applying it once.

Status Codes

CodeMeaningWhen to use
200OKSuccessful GET, PUT, PATCH, or DELETE
201CreatedSuccessful POST that creates a resource
204No ContentSuccessful request with no body to return
400Bad RequestMalformed request, validation error
401UnauthorizedMissing or invalid authentication
403ForbiddenAuthenticated but not allowed
404Not FoundResource doesn't exist
409ConflictResource already exists, or version conflict
429Too Many RequestsRate limited
500Internal Server ErrorUnexpected server error

Error Response Format

Always return structured error responses:

json
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid email address",
    "details": {
      "field": "email",
      "value": "not-an-email"
    }
  }
}

Versioning

Never change a deployed API without versioning. Common approaches:

  • URL versioning: /api/v1/users, /api/v2/users
  • Header versioning: Accept: application/vnd.myapi.v1+json
  • Query parameter: /api/users?version=1

URL versioning is the simplest and most commonly used approach.

Not started

Sign in to save your learning progress.

Sign in to save