api-designlisted

# API Design Principles Design APIs that are intuitive, consistent, and a joy to use. ## URL Structure ### Resources as Nouns ``` # GOOD - nouns GET /users GET /users/123 GET /users/123/orders # BAD - verbs GET /getUsers GET /fetchUserById/123 POST /createNewUser ``` ### Plural Resource Names ``` # GOOD - plural GET /users GET /orders GET /products # BAD - singular GET /user GET /order ``` ### Hierarchical Relationships ``` # Parent-child relationships GET /users/123/orders # Orders for user 123 GET /orders/456/items # Items in order 456 # Avoid deep nesting (max 2 levels) # BAD GET /users/123/orders/456/items/789/reviews # GOOD - flatten when needed GET /order-items/789/reviews ``` ## HTTP Methods | Method | Usage | Idempotent | Safe | |--------|-------|------------|------| | GET | Read resource | Yes | Yes | | POST | Create resource | No | No | | PUT | Replace resource | Yes | No | | PATCH | Partial update | Yes | No | | DELETE | Remove resource | Yes | No | ``` GET /users # List users POST /users # Create user GET /users/123 # Get user 123 PUT /users/123 # Replace user 123 PATCH /users/123 # Update user 123 DELETE /users/123 # Delete user 123 ``` ## Request/Response Format ### Consistent JSON Structure ```json // Success response { "data": { "id": "123", "name": "John Doe", "email": "john@example.com" } } // Collection response { "data": [ { "id": "123", "name": "John"