api-design

Topics in the source

• API Design Patterns
• When to Activate
• Resource Design
• URL Structure
• Naming Rules
• HTTP Methods and Status Codes
• Method Semantics
• Status Code Reference

Conventions and best practices for designing consistent, developer-friendly REST APIs. 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 | Method | Idempotent | Safe | Use For | |--------|-----------|------|---------| | GET | Yes | Yes | Retrieve resources | | POST | No | No | Create resources, trigger actions | | PUT | Yes | No | Full replacement of a resource | | PATCH | No | No | Partial update of a resource | | DELETE | Yes | No | Remove a resource | PATCH can be made idempotent with proper implementation Pros: Easy to implement, supports "jump to page N" Cons: Slow on large offsets (OFFSET 100000), inconsistent with concurrent inserts Pros: Consistent performance regardless of position, stable with concurrent inserts Cons: Cannot jump to arbitrary page, cursor is opaque | Use Case | Pagination Type | |----------|----------------| | Admin dashboards, small datasets (<10K) | Offset | | Infinite scroll, feeds, large datasets | Cursor | | Public APIs | Cursor (default) with offset (optional) | | Search results | Offset (us

This is an excerpt. Refer to the complete source and its current requirements.