RESTful design and naming
RESTful design principles
Follow industry-standard REST conventions.HTTP methods
| Method | Description |
|---|---|
| GET | Retrieve resources |
| POST | Create a new resource |
| PUT | Fully update an existing resource |
| PATCH | Partially update an existing resource |
| DELETE | Delete a resource |
| OPTIONS | Show available methods (optional if docs cover it) |
| HEAD | Same as GET but returns only headers, no response body |
Naming conventions
URI naming
Rules:- Use plural nouns, lowercase, hyphenated names
- No verbs in URLs
- Nest resources only if there is a logical hierarchy or relationship
- Keep nesting shallow (2 levels max)
Resource identifiers: IDs vs UUIDs
Path parameters that identify a single resource should (if possible) use UUIDs. Rules:- UUIDs should be used for externally exposed REST APIs
- Numeric, auto-increment IDs (/users/1) must not be exposed; they have a risk for enumeration
- Only when there is no other way around it you can use auto-increment IDs
- Internal IDs may exist but should never be part of the public API contract
- Prevents ID enumeration and scraping
- Improves security by design
- Decouples API contracts from database implementation details
- Enables safer data migrations and sharding