RESTful API Reference & Cheatsheet — Status Codes, Methods & Best Practices

In this tutorial, you'll learn about RESTful API Reference & Cheatsheet. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

RESTful API reference and cheatsheet for HTTP methods, status codes, caching directives, security patterns, and REST design principles organized for daily use.

What You'll Learn

• HTTP methods with idempotency and safety at a glance
• Complete status code reference (2xx, 3xx, 4xx, 5xx)
• Cache-Control directives and ETag usage
• Standard error response format
• Security patterns and best practices

Why This Reference Matters

Even experienced developers need quick access to status code ranges, method semantics, and header formats. DodaTech's engineering team uses this reference daily when building and maintaining Durga Antivirus Pro's REST API — it ensures consistency across all 50+ endpoints.

flowchart LR
    A["REST Reference"] --> B["HTTP Methods"]
    A --> C["Status Codes"]
    A --> D["Caching"]
    A --> E["Security"]
    A --> F["Error Format"]
    style A fill:#dbeafe,stroke:#2563eb

{{< callout type="info" icon="sparkles" >}} Prerequisites: Familiarity with REST. This is a reference, not a tutorial — use it alongside the RESTful Resources and RESTful Methods. {{< /callout >}}

HTTP Methods Reference

Safe: No server-side side effects. Idempotent: N identical requests produce the same server State as 1 request.

Status Codes Quick Reference

2xx Success

3xx Redirection

4xx Client Error

5xx Server Error

Cache-Control Directives

Standard Error Response Format

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Human-readable summary",
    "details": [
      { "field": "email", "message": "Must be valid email" }
    ],
    "requestId": "req-abc-123"
  }
}

Security Reference

Design Principles Reference

• Nouns, not verbs: /users, not /getUsers
• Plural collections: /users, /products, /threats
• Nested scope: /users/{id}/orders
• Versioned: /api/v1/...
• Consistent errors: Same JSON structure everywhere
• Idempotent methods: PUT, DELETE (same call, same result)
• Stateless: No server-side sessions, JWT carries State

Common Mistakes

1. Inconsistent error formats — clients need different parsers per endpoint
2. Not versioning — breaking changes break all existing clients
3. Returning 200 for everything — loses semantic meaning
4. No caching headers — caches behave unpredictably
5. Session State on server — breaks horizontal scaling
6. Exposing internal IDs — couples API to DB schema

Practice Questions

1. What status code should a POST request return on success?
2. Which HTTP methods are idempotent and why?
3. What Cache-Control directive prevents any caching?
4. What is the difference between 401 and 403?
5. How does JWT maintain statelessness?

Answers:

1. 201 Created with a Location header pointing to the new resource.
2. GET, PUT, DELETE — calling them multiple times produces the same server State.
3. Cache-Control: no-store
4. 401 = not authenticated (missing/invalid credentials). 403 = authenticated but not authorized.
5. The JWT contains all user data (ID, role, permissions) signed by the server — no database lookup needed, no server-side State.

Challenge: Create a 5-line implementation of a rate limiter middleware for Express.js that tracks requests by IP and returns 429 when the limit is exceeded.

FAQ

What's Next