Why standardize error response shapes?
So clients can rely on the shape. If one endpoint returns { error: 'msg' } and another returns { errors: [...] }, clients have to special-case each one. Pick one shape (e.g., { error: 'msg', code: 'X' }) and use it everywhere.
Verify This Answer
Cross-check this information using these trusted sources:
More FAQs in Common API Design Mistakes (and How to Avoid Them)
Verbs in paths, wrong status codes, no versioning, no pagination, inconsistent response shapes, exposing internals, no validation, GET with side effects, no error format, deep nesting, no rate limiting, and no documentation.
Because the HTTP method is the verb. /users, not /getUsers. /users/:id, not /getUserById. Plural nouns for collections. This is the REST convention and matches what clients expect.
Returning every user in one response is slow, uses memory, and breaks clients. Cap the response with a limit (max 100). Use skip and limit, or cursor-based. Return total for offset pagination.
Still have questions?
Browse all our FAQs or reach out to our support team