REST API Cheat Sheet

Updated 2026-07-16

🎯Take a practice test on this topic9 practice tests · 257 questions→

🧠Study flashcards on this topic165 cards · spaced repetition→

REST (Representational State Transfer) is an architectural style for designing networked applications that uses HTTP as the transport protocol and treats everything as a resource accessible via a unique URI. REST APIs enable stateless client-server communication through standard HTTP methods, making them the dominant approach for building web services. The key principle to remember: REST APIs model your application domain as resources, not remote procedures — the URI identifies what resource you're working with, and the HTTP method tells the server what action to take on that resource.

What This Cheat Sheet Covers

This topic spans 28 focused tables and 194 indexed concepts, 165 flashcards, 9 practice tests with 257 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Principles and ConstraintsTable 2: HTTP Methods (Verbs)Table 3: HTTP Status Codes (2xx Success)Table 4: HTTP Status Codes (3xx Redirection)Table 5: HTTP Status Codes (4xx Client Errors)Table 6: HTTP Status Codes (5xx Server Errors)Table 7: Request HeadersTable 8: Response HeadersTable 9: Authentication MethodsTable 10: API Versioning StrategiesTable 11: Resource Naming ConventionsTable 12: API Design PatternsTable 13: Pagination TechniquesTable 14: Filtering and SortingTable 15: Caching MechanismsTable 16: Error Response PatternsTable 17: Rate LimitingTable 18: CORS (Cross-Origin Resource Sharing)Table 19: HATEOAS and HypermediaTable 20: Richardson Maturity ModelTable 21: Asynchronous PatternsTable 22: Bulk and Batch OperationsTable 23: Content NegotiationTable 24: CompressionTable 25: Request/Response Body DesignTable 26: Security Best PracticesTable 27: OpenAPI / Swagger DocumentationTable 28: Idempotency and Safety

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Principles and Constraints

These are the architectural constraints Roy Fielding set out in his 2000 dissertation, and they are what separate genuinely RESTful design from plain "HTTP with JSON." Statelessness shapes the most decisions, since keeping session state on the client is what lets any server in a pool answer any request. Six of the seven are required; code-on-demand is the one you are free to skip.

Principle	Example	Description
Stateless	Each request includes `Authorization: Bearer <token>` to authenticate independently	• Every request must contain all information needed to process it • server keeps no client session state between requests, though a database is still fine
Client-Server Separation	Client handles UI; server handles data storage and business logic separately	• Decouples user interface concerns from data storage, so both evolve independently • a boundary of concerns, not of machines
Uniform Interface	Resources identified by URIs; manipulated via standard HTTP methods (GET, POST, etc.)	• Simplifies and decouples the architecture • four sub-constraints: resource identification, manipulation via representations, self-descriptive messages, hypermedia • format-agnostic: JSON is convention, not a rule
Resource-Based	`/users/123` identifies a user resource; the JSON returned represents it	• A URI identifies a resource, meaning a concept, not a database row • what transfers is a representation, never the resource itself
Cacheable	`Cache-Control: max-age=3600` on GET response	• Responses must label themselves cacheable or not, implicitly or explicitly • declaring a response non-cacheable satisfies the constraint
Layered System	Client → CDN → Load Balancer → Backend Server	• Client cannot tell whether it reached the origin server or an intermediary • lets you insert caches, gateways, and load balancers without changing clients
Code-on-Demand	Server returns JavaScript the browser downloads and runs	• Server may extend client behavior by sending executable code such as scripts or applets • the only optional constraint, since downloaded code reduces visibility

Table 2: HTTP Methods (Verbs)

The verb tells the server what you are asking it to do with a resource. The everyday mapping (GET reads, POST submits, PUT replaces, PATCH edits, DELETE removes) is a good starting point, but RFC 9110 is more precise than the CRUD table suggests: PUT can create, and POST simply asks the target resource to process your payload however it sees fit. Two properties travel with the verbs: safe means the client is not asking for a state change (the server may still log or bill), and idempotent means repeating the request lands on the same state.

Method	Example	Description
GET	`GET /api/users/123`	• Retrieve a representation of a resource • safe and idempotent, so caches, spiders, and pre-fetchers may repeat it freely

The rest of this section is part of the full cheat sheet

Table 3: HTTP Status Codes (2xx Success)

A 2xx code tells the client its request succeeded, but picking the right one says far more than a blanket 200. Reach for 201 after creating a resource, 204 when a delete leaves nothing to send back, and 202 for work you have queued but not finished. The 206 and 207 codes at the end cover range requests and per-item batch outcomes.

Code	Example	Description
200 OK	`GET /api/users` → `200 OK` with user list	• Standard successful response • request succeeded, and the body's meaning depends on the method: for GET it is the resource, for POST the result of the action

The rest of this section is part of the full cheat sheet

Table 4: HTTP Status Codes (3xx Redirection)

Redirection codes point a client somewhere else or tell it nothing has changed. The pair worth real attention is 307 and 308: RFC 9110 lets a client turn a redirected POST into a GET on a 301 or 302 (a historical quirk that browsers converged on), while 307 and 308 forbid the method change outright. The 304 Not Modified code is the workhorse behind conditional caching.

Code	Example	Description
301 Moved Permanently	`GET /api/v1/users` → `301` `Location: /api/v2/users`	• Resource has permanently moved to new URI • client should use new URI for future requests • a client MAY change a redirected POST to GET, so use 308 when the method must survive

The rest of this section is part of the full cheat sheet

Table 1: Core Principles and Constraints

Principle	Example	Description
Stateless	Each request includes `Authorization: Bearer <token>` to authenticate independently	• Every request must contain all information needed to process it • server keeps no client session state between requests, though a database is still fine
Client-Server Separation	Client handles UI; server handles data storage and business logic separately	• Decouples user interface concerns from data storage, so both evolve independently • a boundary of concerns, not of machines
Uniform Interface	Resources identified by URIs; manipulated via standard HTTP methods (GET, POST, etc.)	• Simplifies and decouples the architecture • four sub-constraints: resource identification, manipulation via representations, self-descriptive messages, hypermedia • format-agnostic: JSON is convention, not a rule
Resource-Based	`/users/123` identifies a user resource; the JSON returned represents it	• A URI identifies a resource, meaning a concept, not a database row • what transfers is a representation, never the resource itself
Cacheable	`Cache-Control: max-age=3600` on GET response	• Responses must label themselves cacheable or not, implicitly or explicitly • declaring a response non-cacheable satisfies the constraint
Layered System	Client → CDN → Load Balancer → Backend Server	• Client cannot tell whether it reached the origin server or an intermediary • lets you insert caches, gateways, and load balancers without changing clients
Code-on-Demand	Server returns JavaScript the browser downloads and runs	• Server may extend client behavior by sending executable code such as scripts or applets • the only optional constraint, since downloaded code reduces visibility

Table 2: HTTP Methods (Verbs)

Method	Example	Description
GET	`GET /api/users/123`	• Retrieve a representation of a resource • safe and idempotent, so caches, spiders, and pre-fetchers may repeat it freely

Table 3: HTTP Status Codes (2xx Success)

Code	Example	Description
200 OK	`GET /api/users` → `200 OK` with user list	• Standard successful response • request succeeded, and the body's meaning depends on the method: for GET it is the resource, for POST the result of the action

Table 4: HTTP Status Codes (3xx Redirection)

Code	Example	Description
301 Moved Permanently	`GET /api/v1/users` → `301` `Location: /api/v2/users`	• Resource has permanently moved to new URI • client should use new URI for future requests • a client MAY change a redirected POST to GET, so use 308 when the method must survive