This chapter is not a tutorial. It is a condensed reference for everything covered in the REST API series, organized for lookup rather than reading. Each section maps to a chapter, keeps only the facts that matter in practice, and omits the explanations that the chapters already provide. Use it when you know what you are looking for and need the exact syntax, status code, or header value without re-reading the full treatment.
Key point: A cheatsheet is useful only if it is accurate. Every entry here corresponds to a verified fact from the preceding twenty-five chapters. When in doubt, return to the source chapter rather than improvising.
01. REST and Architectural Constraints
Constraint
Meaning
Client-server
UI and data storage separate; independent evolution
Stateless
Each request carries all context; no server session
Cacheable
Responses must declare cacheability
Uniform interface
Resources identified by URIs; manipulation via representations
Layered system
Client sees only the immediate layer
Code on demand (optional)
Server may send executable code
Principle
Rule
Resource identification
Everything is a resource; URIs name them
Representation
JSON is a representation, not the resource
Statelessness
Every request includes auth and context
02. Resources, URIs, and Naming
Convention
Example
Plural nouns
/users, /orders
Hierarchical
/users/42/orders
No verbs in paths
/users/42 not /getUser/42
Lowercase, hyphens
/user-profiles not /userProfiles
No file extensions
/users not /users.json
Pattern
URI
Collection
GET /users
Single item
GET /users/42
Sub-collection
GET /users/42/orders
Sub-item
GET /users/42/orders/7
03. HTTP Methods
Method
Semantics
Safe
Idempotent
Body
GET
Read resource
Yes
Yes
No
POST
Create / non-idempotent action
No
No
Yes
PUT
Replace entire resource
No
Yes
Yes
PATCH
Partial update
No
Not guaranteed
Yes
DELETE
Remove resource
No
Yes
No
HEAD
Metadata only
Yes
Yes
No
OPTIONS
Capabilities / CORS preflight
Yes
Yes
No
Rule
Detail
GET has no side effects
Never mutate on GET
PUT replaces
Omitted fields are removed
PATCH merges
Omitted fields are untouched
04. Request and Response Headers
Header
Direction
Purpose
Content-Type
Request
Format of sent body
Accept
Request
Desired response format
Authorization
Request
Credentials
User-Agent
Request
Client identification
Content-Type
Response
Format of response body
Location
Response
URI of created resource (201)
ETag
Response
Version tag for caching
Cache-Control
Both
Caching directives
Value
Meaning
application/json
JSON body
application/problem+json
RFC 7807 error
application/x-www-form-urlencoded
Form body
multipart/form-data
File upload
05. Status Codes
Code
Meaning
Use
200
OK
Successful GET/PUT/PATCH
201
Created
Successful POST; include Location
204
No Content
Successful DELETE, no body
301 / 308
Moved Permanently
URI changed
304
Not Modified
Client cache is valid
400
Bad Request
Malformed syntax
401
Unauthorized
Missing/invalid credentials
403
Forbidden
Authenticated, not permitted
404
Not Found
Resource absent (also for unauthorized objects)
409
Conflict
State conflict (duplicate, version)
422
Unprocessable Entity
Valid syntax, invalid semantics
429
Too Many Requests
Rate limited
500
Internal Server Error
Unexpected failure
502
Bad Gateway
Upstream failure
503
Service Unavailable
Temporarily down
06. JSON Payload Design
Rule
Example
camelCase or snake_case, one convention
{"firstName": "A"} or {"first_name": "A"}
Consistent date format
ISO 8601: "2026-10-21T14:32:00Z"
No null for absent optional fields
Omit the field
IDs as strings if opaque
"id": "ord_8871"
No trailing commas
Invalid JSON
Anti-pattern
Fix
Mixed conventions
Pick one, enforce with schema
Numbers as strings
"total": 99.99 not "99.99"
Nulls everywhere
Omit optional fields
07. Query Parameters
Purpose
Syntax
Filter
?status=active&role=admin
Sort
?sort=-created_at,name
Search
?q=widget
Fields
?fields=id,name
Pagination
?limit=20&offset=40
Rule
Detail
- prefix for descending
?sort=-created_at
Commas for multiple values
?fields=id,name
Array syntax for repeated
?tag=a&tag=b or ?tag[]=a&tag[]=b
08. Pagination
Strategy
Params
Pros
Cons
Offset
?limit=20&offset=40
Simple, jump to page
Slow on deep pages
Cursor
?limit=20&cursor=abc
Stable under inserts
No random access
Keyset
?after=1043&limit=20
Efficient
Requires indexed key
Response field
Purpose
items or data
Current page
next_cursor
Opaque cursor for next page
has_more
Whether more pages exist
total
Total count (offset only)
09. Input Validation and Error Handling
Validation
When
Schema validation
At request boundary, before business logic
Type coercion
Reject wrong types, do not coerce silently
Length limits
Strings, arrays, bodies
Range checks
Numbers, dates
Allow-list
Enums, not free-form strings
Error field
Purpose
type
URI identifying error class
title
Human-readable summary
detail
Specific explanation
instance
Request URI
10. RFC 7807 Problem Details
Field
Type
Purpose
type
string (URI)
Error class
title
string
Short summary
status
integer
HTTP status
detail
string
Specific explanation
instance
string (URI)
Request URI
(extension)
any
Additional context
{
"type": "https://example.com/errors/validation",
"title": "Validation failed",
"status": 422,
"detail": "The 'email' field is not a valid address.",
"instance": "/api/users"
}
Media type: application/problem+json.
11. Authentication Methods
Method
Header
Use When
API key
X-API-Key: <key> or Authorization: ApiKey <key>
Server-to-server
Basic
Authorization: Basic <base64(user:pass)>
Only over HTTPS, legacy
Bearer
Authorization: Bearer <token>
User sessions, OAuth
Rule
Detail
Never in URL
Keys in query strings are logged
Always over HTTPS
Credentials in plaintext otherwise
Rotate keys
Support multiple active keys during rotation
12. JWT and Refresh Tokens
JWT part
Content
Header
{"alg": "HS256", "typ": "JWT"}
Payload
Claims: sub, exp, iat, iss, aud
Signature
HMAC or RSA over header + payload
Claim
Purpose
sub
Subject (user ID)
exp
Expiration (Unix time)
iat
Issued at
iss
Issuer
aud
Audience
Rule
Detail
Validate alg
Reject none
Validate exp
Reject expired
Validate signature
Always, server-side
Short-lived access
5–15 minutes
Refresh rotation
One-time refresh tokens
13. OAuth 2.0 and OIDC
Flow
Use When
Authorization Code + PKCE
Web and mobile apps
Client Credentials
Server-to-server
Device Code
Input-constrained devices
Implicit (deprecated)
Never; use PKCE
Endpoint
Purpose
/authorize
User grants consent
/token
Exchange code for tokens
/introspect
Validate opaque token
/.well-known/openid-configuration
OIDC discovery
OIDC token
Purpose
ID token (JWT)
User identity claims
Access token
API access
Refresh token
Obtain new access tokens
14. RBAC vs ABAC
Model
Basis
Example
RBAC
Role of caller
admin can delete users
ABAC
Attributes of caller + resource
owner can edit own document
ReBAC
Relationship graph
member of team can access repo
Rule
Detail
Never trust client-declared roles
Roles come from the server’s identity store
Object-level check is separate
RBAC does not cover ownership (API1)
Policy engine
OPA, Casbin for centralized rules
15. CORS
Header
Purpose
Access-Control-Allow-Origin
Allowed origin(s)
Access-Control-Allow-Methods
Allowed HTTP methods
Access-Control-Allow-Headers
Allowed request headers
Access-Control-Allow-Credentials
Send cookies
Access-Control-Max-Age
Preflight cache duration
Rule
Detail
Never * with credentials
Browser rejects it
Explicit origins
https://app.example.com
Preflight for non-simple
Custom headers, PUT, DELETE
16. Rate Limiting
Header
Meaning
X-RateLimit-Limit
Max requests per window
X-RateLimit-Remaining
Remaining in window
X-RateLimit-Reset
Window reset time
Retry-After
Seconds to wait (429)
Algorithm
Behavior
Fixed window
Simple, burst at boundary
Sliding window
Smoother, more memory
Token bucket
Allows bursts up to capacity
Leaky bucket
Constant output rate
Rule
Detail
Per-consumer limits
Not just per-IP
429 with Retry-After
Tell client when to retry
Separate login limits
5/min for credential endpoints
17. Caching
Header
Purpose
Cache-Control: public, max-age=3600
Cacheable for 1 hour
Cache-Control: private, no-store
Never cache
ETag
Version identifier
Last-Modified
Timestamp version
If-None-Match
Conditional request (ETag)
If-Modified-Since
Conditional request (date)
Status
Meaning
200
Fresh response
304
Not Modified; use cache
412
Precondition failed
Rule
Detail
ETag for per-resource
Strong or weak (W/"...")
Vary for negotiation
Vary: Accept-Encoding, Accept-Language
No caching for sensitive data
no-store
18. API Versioning
Strategy
Example
Pros
Cons
URI
/v1/users
Explicit, cacheable
URI churn
Query
?version=1
Simple
Easy to miss
Header
Accept: application/vnd.api+json; version=1
Clean URI
Hidden
Content negotiation
Accept-Version: 1
Flexible
Harder to debug
Rule
Detail
Breaking change = new version
Additive changes do not need one
Deprecation headers
Sunset, Deprecation
Support overlap
Old and new version coexist during migration
19. Idempotency Keys
Header
Purpose
Idempotency-Key: <uuid>
Client-generated unique key
Rule
Detail
Stored server-side
Key → response mapping
TTL
24–48 hours typical
Same key, same response
Replay returns original result
Key per attempt
Retries reuse; new operations use new key
Required for POST
Only for non-idempotent writes
20. API Testing Tools
Tool
Type
Use
cURL
CLI
Quick checks, scripts
Postman
GUI
Collections, environments, collaboration
Bruno
GUI/CLI
Git-friendly, offline-first
httpie
CLI
Human-readable output
Newman
CLI
Run Postman collections in CI
cURL command
Purpose
curl -X POST -H "Content-Type: application/json" -d '{}' URL
POST JSON
curl -H "Authorization: Bearer $TOKEN" URL
Authenticated GET
curl -i URL
Include headers in output
curl -o file URL
Save body to file
21. Automated Testing
Test type
Scope
Speed
Unit
Single function
Milliseconds
Integration
API + real DB
Seconds
End-to-end
Full workflow
Minutes
Schema validation
Response structure
Milliseconds
Rule
Detail
Integration asserts persistence
Query DB after HTTP call
Mock external services
Real internal dependencies
Factories for test data
Never depend on seed data
CI staging
Unit → Integration → E2E
22. OpenAPI and Swagger
Section
Purpose
openapi
Spec version (3.0.3, 3.1.0)
info
Title, version, description
servers
Base URLs
paths
Endpoint definitions
components
Reusable schemas, security
Tool
Purpose
Swagger Editor
Author and validate
Swagger UI
Interactive rendering
Redoc
Read-only reference
OpenAPI Generator
Client SDK generation
Redocly CLI
Lint, bundle, build
Command
Purpose
redocly lint openapi.yaml
Validate
redocly build-docs openapi.yaml
Static HTML
redocly bundle openapi.yaml
Resolve $ref
23. Webhooks
Handler stage
Action
Failure response
1
Verify signature on raw body
401
2
Parse JSON
400
3
Check event ID for duplicate
200 (no side effect)
4
Process event
5xx (retry)
5
Mark processed, acknowledge
200
Header
Purpose
X-Webhook-Signature
HMAC-SHA256 of raw body
X-Webhook-Timestamp
Replay protection
X-Webhook-Id
Idempotency key (alternate)
Response
Provider behavior
2xx
No retry
4xx (except 429)
No retry
429
Retry after delay
5xx
Retry with backoff
Rule
Detail
Verify before parsing
Signature covers raw bytes
Constant-time compare
hmac.compare_digest
Queue-first
Enqueue, return 2xx, process async
Reconciliation
Poll API for missed events
24. OWASP API Top 10 (2023)
Risk
Failure
Fix
API1 BOLA
Object accessed without ownership check
Scope query to authenticated user
API2 Broken Auth
Tokens unverified
Validate signature, expiry, algorithm
API3 Property Auth
Mass assignment, data exposure
Allow-list request and response
API4 Resource Use
No size or cost limits
Server-enforced caps
API5 Function Auth
Admin endpoint open to users
Centralized role middleware
API6 Business Flow
Automation abuse
CAPTCHA, fingerprinting
API7 SSRF
User URL fetched unchecked
Allow-list hosts, block private IPs
API8 Misconfiguration
Wildcard CORS, verbose errors
Explicit origins, generic errors
API9 Inventory
Forgotten endpoints
Endpoint inventory, deprecation
API10 Unsafe Consumption
Third-party data trusted
Schema validation
Rule
Detail
BOLA fix is a query change
WHERE id=? AND user_id=?
404 for unauthorized
Avoids enumeration signal
Allow-list both directions
Request body and response body
Gateway is not authorization
Services still enforce object-level
25. Gateways, Proxies, Load Balancing
Component
Primary job
Scope
Reverse proxy
Forward and secure
Infrastructure
Load balancer
Distribute across replicas
Availability
API gateway
Govern API consumers
Policy and identity
NGINX directive
Purpose
upstream
Define backend group
proxy_pass
Forward to upstream
least_conn
Least-connections algorithm
ip_hash
Session persistence
max_fails / fail_timeout
Passive health checks
limit_req_zone
Rate limiting
proxy_set_header X-Real-IP
Forward client IP
Layer
Job
L4 load balancer
Distribute TCP connections
API gateway
Per-route auth, quotas
Service mesh
East-west mTLS, retries
Rule
Detail
One job per layer
Remove layers that duplicate
Gateway latency
~5–9ms p99 versus plain proxy
Trace >20% proxy time
Remove redundancy
Do not use gateway for single service
Reverse proxy costs less
Summary
Chapter
Core takeaway
01
REST is six constraints; statelessness is the defining one
The most common production bugs are authorization gaps. Chapters 14 and 24 are the ones to revisit when an API is compromised. BOLA accounts for the single largest category of real-world API incidents, and its fix is a query change, not a framework upgrade.
Idempotency is the difference between a retry and a duplicate. Chapters 03, 19, and 23 all touch this. GET, PUT, and DELETE are safe to retry by design. POST requires an Idempotency-Key. Webhook handlers require an event ID check.
HTTP status codes carry semantics that clients depend on. Returning 200 with {"error": ...} breaks every client that checks status codes. 201 with Location, 204 with no body, 404 for both missing and unauthorized — these are contracts, not suggestions.
Caching is a contract between client and server.Cache-Control, ETag, If-None-Match, and 304 are the mechanism. A server that omits Cache-Control on a cacheable response forces clients to re-download data that has not changed.
The testing pyramid is a division of responsibility. Unit tests catch logic errors. Integration tests catch wiring errors. End-to-end tests catch workflow errors. None substitutes for the others, and CI staging keeps feedback fast.
The OpenAPI spec is the source; everything else is derived. Documentation, client SDKs, mock servers, and contract tests all read the same file. Hand-editing the rendered docs instead of the spec guarantees drift.
Security is structural, not additive. Authorization in the data access layer, allow-lists for fields, server-enforced limits, and centralized role checks prevent entire classes of vulnerabilities by construction.
Remember: This cheatsheet compresses twenty-five chapters into lookup tables. It is useful for confirming syntax, checking a status code, or finding the right header name. It is not a substitute for the chapters themselves when you need to understand why a pattern exists or how to apply it to a situation the tables do not cover. The most valuable entries are the ones that are easy to get wrong: idempotency keys, RFC 7807 format, CORS credentials rules, JWT alg validation, BOLA query scoping, and webhook signature verification. These are the details that separate an API that works in a demo from one that survives production.
Was this helpful?
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for: ✅ Finance (Mortgage, Interest, Inflation) ✅ Tech (Base64, JSON, Dev Suite, IP) ✅ Health (BMI, BMR, TDEE) ✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private 🔒 No data leaves your device 💎 100% Free