| # API Design Principles | |
| ## Introduction | |
| Good API design is crucial for developer experience. This document outlines the core principles we follow when designing REST APIs. | |
| ## Principle 1: Use Nouns, Not Verbs | |
| URLs should represent resources, not actions. Use HTTP methods to indicate the action. | |
| **Good:** | |
| - GET /users/123 | |
| - POST /orders | |
| - DELETE /products/456 | |
| **Bad:** | |
| - GET /getUser?id=123 | |
| - POST /createOrder | |
| - GET /deleteProduct/456 | |
| ## Principle 2: Use Plural Nouns | |
| Always use plural nouns for consistency. | |
| - /users (not /user) | |
| - /orders (not /order) | |
| - /products (not /product) | |
| ## Principle 3: Hierarchical Relationships | |
| Express relationships through URL hierarchy. | |
| - GET /users/123/orders - Get all orders for user 123 | |
| - GET /users/123/orders/456 - Get specific order 456 for user 123 | |
| ## Principle 4: Filtering and Pagination | |
| Use query parameters for filtering, sorting, and pagination. | |
| - GET /products?category=electronics&sort=price&page=2&limit=20 | |
| ## Principle 5: Versioning | |
| Always version your APIs. We prefer URL versioning. | |
| - /v1/users | |
| - /v2/users | |
| ## Principle 6: Error Handling | |
| Return consistent error responses with appropriate HTTP status codes. | |
| ```json | |
| { | |
| "error": { | |
| "code": "VALIDATION_ERROR", | |
| "message": "Email format is invalid", | |
| "field": "email" | |
| } | |
| } | |
| ``` | |
| ## Principle 7: Rate Limiting | |
| Implement rate limiting and communicate limits via headers: | |
| - X-RateLimit-Limit: 1000 | |
| - X-RateLimit-Remaining: 999 | |
| - X-RateLimit-Reset: 1640000000 | |
| ## Conclusion | |
| Following these principles leads to APIs that are intuitive, consistent, and easy to maintain. Remember: the best API is one that developers can use without reading documentation. | |