BackendPrep
All Guides/APIs & Protocols/REST API Design: Resources, Status Codes and Error Handling
API ArchitectureAPIs & ProtocolsBeginner14 min read

REST API Design: Resources, Status Codes and Error Handling

A complete guide to designing intuitive, consistent, and production-grade REST APIs — covering resource modeling, HTTP verb semantics, status code taxonomy, and standardized RFC 7807 error responses.

Technologies:APIsRESTProtocolsHTTP
Foundational Principles vs Practical Heuristics
Universal Principle (Inviolable Truth):

HTTP method semantics are defined by RFC specifications: GET, HEAD, and OPTIONS must be safe (read-only); PUT and DELETE must be idempotent; POST is neither safe nor idempotent.

Practical Heuristic (Rule of Thumb):

Never return `200 OK` with an `{ error: true }` body. Use standard HTTP status codes so API gateways, CDNs, client SDKs, and monitoring tools can accurately classify errors.

Production Illustrative Example:Returning `200 OK` for an invalid password prevents reverse proxies from logging 4xx client errors and causes uptime monitors to report that the authentication service is 100% healthy.
Target Competencies & Learning Outcomes:
  • Model clean resource hierarchies using nouns and pluralized endpoints
  • Differentiate safe, idempotent, and non-idempotent HTTP methods (GET, POST, PUT, PATCH, DELETE)
  • Select accurate HTTP status codes across the 2xx, 4xx, and 5xx families
  • Implement RFC 7807 (Problem Details for HTTP APIs) for consistent client error handling

1. Resource-Oriented URL Modeling

Free Chapter Preview

REST APIs should model resources (nouns), not remote procedure calls (verbs):

TypeScript / Node.js
// BAD (RPC disguised as REST):
POST /getUserDetails
POST /createNewOrder
POST /deleteUser?id=42

// GOOD (Resource-Oriented REST):
GET    /api/v1/users/42
POST   /api/v1/orders
DELETE /api/v1/users/42

Hierarchical Sub-Resources

Use nested paths to represent relationships where the child cannot exist without the parent:

  • GET /api/v1/users/42/orders: Orders belonging to user 42.
  • POST /api/v1/users/42/orders: Create an order for user 42.
[!TIP] Avoid nesting deeper than two levels (e.g., avoid /users/42/orders/10/items/3/taxes). Use top-level endpoints with query filters instead: GET /api/v1/order-items?order_id=10.

2. HTTP Verbs: Safe vs Idempotent Semantics

In this section, we examine the production failure mechanics, internal socket buffers, and kernel-level trace diagnostics...

100% Free Knowledge Library

Sign In to Read the Full Guide

Unlock all remaining 5 chapters of REST API Design: Resources, Status Codes and Error Handling. Get complete production code snippets, architectural trade-offs, and track your reading completion.

Explore Other Guides
✓ Free Google / GitHub Sign-In•✓ No Subscription Required•✓ Instant Access