Skip to main content
Conventions and best practices for designing consistent, developer-friendly REST APIs.

When to Activate

  • Designing new API endpoints
  • Reviewing existing API contracts
  • Adding pagination, filtering, or sorting
  • Implementing error handling for APIs
  • Planning API versioning strategy
  • Building public or partner-facing APIs

Resource Design

URL Structure

HTTP Methods and Status Codes

Method Semantics

Status Code Reference

Response Format

Success Response

Collection Response (with Pagination)

Error Response

Pagination

Offset-Based (Simple)

Pros: Easy to implement, supports “jump to page N” Cons: Slow on large offsets, inconsistent with concurrent inserts

Cursor-Based (Scalable)

Pros: Consistent performance, stable with concurrent inserts Cons: Cannot jump to arbitrary page, cursor is opaque

Filtering

Sorting

API Design Checklist

Before shipping a new endpoint:
  • Resource URL follows naming conventions (plural, kebab-case, no verbs)
  • Correct HTTP method used (GET for reads, POST for creates, etc.)
  • Appropriate status codes returned (not 200 for everything)
  • Input validated with schema (Zod, Pydantic, Bean Validation)
  • Error responses follow standard format with codes and messages
  • Pagination implemented for list endpoints (cursor or offset)
  • Authentication required (or explicitly marked as public)
  • Authorization checked (user can only access their own resources)
  • Rate limiting configured
  • Response does not leak internal details (stack traces, SQL errors)
  • Consistent naming with existing endpoints (camelCase vs snake_case)
  • Documented (OpenAPI/Swagger spec updated)