GET /users
- It may be missing query semantics: GET /users?page=1&limit=50&status=active
- Might also need GET /users/:id for a single user
POST /users/new
- Redundant “new” in the path. In REST create a resource by method post like POST /users with the new user data in the body
POST /users/:id/update
- Wrong HTTP method: Update are typically PUT or PATCH. Using POST loses idempotency semantics and is confusing.
- Verb “/update” in the path
- Again PRC style. REST would use the resource itself
PUT /users/:id (replace)
PATCH /users/:id (partial update)- Ambiguous semantics: Does it replace all fields? Some fields? No clear contract.
POST /users/:id/rename
- Action-specific endpoint instead of generic update: Renaming is just updating one field name/fullname/nickname, which fits naturally into PATCH /users/:id
- HTTP method again /rename Suggest
PATCH /users/:id
{
"name": "New Name"
}
POST /users/:id/update-timezone
- Using POST instead of PATCH for update
- Special-case update that should be part of a generic update mechanism
- So we have two ways to implement this, depending on the use case and its related dependencies
PATCH /users/:id {"timezone": "Asia/Ho_Chi_Minh" }
PUT /users/:id/timezone {"value": "Asia/Ho_Chi_Minh"}
DELETE /users/delete?id=:id
- /users/delete is clearly an action, not a resource.
- ID in query instead of path
- Redundant “delete” in both path and HTTP method Suggest:
DELETE /users/:id
Summary: Inconsistencies across the whole API
- Inconsistent resource identification
Sometimes the ID is in the path (/users/:id/...) Sometimes in the query (/users/delete?id=:id)
- Verb-centric URIs
- Misuse of HTTP methods
- POST used for what should be idempotent updates (update, rename, update-timezone).
- DELETE used with an extra “delete” in path.