HeoLab
ToolsBlogAboutContact
HeoLab

Free developer tools with AI enhancement. Built for developers who ship.

Tools

  • JSON Formatter
  • JWT Decoder
  • Base64 Encoder
  • Timestamp Converter
  • Regex Tester
  • All Tools →

Resources

  • Blog
  • What is JSON?
  • JWT Deep Dive
  • Base64 Explained

Company

  • About
  • Contact
  • Privacy Policy
  • Terms of Service

© 2026 HeoLab. All rights reserved.

Tools work in your browser. Zero data retention.

HomeBlogREST API Design Best Practices: A Complete Guide
Table of Contents▾
  • Table of Contents
  • Resource Naming
  • HTTP Methods and Semantics
  • Status Codes
  • Request and Response Structure
  • Versioning
  • Error Handling
api#rest-api#api-design#backend

REST API Design Best Practices: A Complete Guide

Design REST APIs that developers love — resource naming, HTTP methods, status codes, versioning, and error handling conventions.

Trong Ngo
February 26, 2026
2 min read

Table of Contents

  • Resource Naming
  • HTTP Methods and Semantics
  • Status Codes
  • Request and Response Structure
  • Versioning
  • Error Handling

Resource Naming

URLs should represent resources (nouns), not actions (verbs). Use plural nouns.

✅ Good
GET    /users          → list users
GET    /users/123      → get user 123
POST   /users          → create user
PUT    /users/123      → replace user 123
PATCH  /users/123      → partially update user 123
DELETE /users/123      → delete user 123

❌ Bad
GET  /getUsers
POST /createUser
GET  /deleteUser?id=123

For nested resources:

GET /users/123/orders        → orders belonging to user 123
GET /users/123/orders/456    → specific order

HTTP Methods and Semantics

MethodPurposeIdempotentSafe
GETReadYesYes
POSTCreateNoNo
PUTReplaceYesNo
PATCHPartial updateNoNo
DELETEDeleteYesNo

Idempotent: calling it multiple times produces the same result. GET, PUT, DELETE are idempotent — POST is not.

Status Codes

Use the right status code — don't return 200 OK for errors.

200 OK              → successful GET, PATCH
201 Created         → successful POST
204 No Content      → successful DELETE
400 Bad Request     → invalid input
401 Unauthorized    → not authenticated
403 Forbidden       → authenticated but no permission
404 Not Found       → resource doesn't exist
409 Conflict        → duplicate, version mismatch
422 Unprocessable   → validation failed
429 Too Many Requests → rate limited
500 Internal Server Error → bug on your end

Request and Response Structure

// POST /users — request body
{
  "name": "Trong Ngo",
  "email": "trong@example.com",
  "role": "admin"
}

// 201 Created — response
{
  "id": "usr_abc123",
  "name": "Trong Ngo",
  "email": "trong@example.com",
  "role": "admin",
  "createdAt": "2025-06-01T10:00:00Z"
}

Versioning

URL versioning (most common):    /v1/users
Header versioning:               Accept: application/vnd.api+json;version=1
Query param (least preferred):   /users?version=1

Always version your public API from day one — it's painful to add later.

Error Handling

Return structured, actionable errors:

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "Request validation failed",
    "details": [
      { "field": "email", "message": "Must be a valid email address" },
      { "field": "name", "message": "Required" }
    ]
  }
}

Related Articles

Unit Testing Best Practices in JavaScript

3 min read

Clean Code Principles Every Developer Should Know

3 min read

PostgreSQL Performance Tuning: Indexes, Query Plans, and EXPLAIN ANALYZE

5 min read

Back to Blog

Table of Contents

  • Table of Contents
  • Resource Naming
  • HTTP Methods and Semantics
  • Status Codes
  • Request and Response Structure
  • Versioning
  • Error Handling

Related Articles

Unit Testing Best Practices in JavaScript

3 min read

Clean Code Principles Every Developer Should Know

3 min read

PostgreSQL Performance Tuning: Indexes, Query Plans, and EXPLAIN ANALYZE

5 min read