What principles do you follow when designing RESTful APIs?
Reported in Supercell European engineering loops. API design question covering resources, HTTP semantics, and versioning.
Interview scenario
Often asked in Supercell loops at European offices (London, Berlin, Amsterdam, Paris, Stockholm, Dublin, and remote EU). Prepare a clear spoken answer plus key trade-offs.
Model answer
Try answering aloud first
Cover trade-offs, structure, and a concrete example before revealing the baseline response.
How to frame this at Supercell: Connect your answer to measurable impact, clarity of thought, and trade-offs the team cares about. Below is a strong baseline response you can adapt with your own project examples.
Model resources as nouns (/users/{id}/orders), not verbs. Use HTTP methods correctly: GET (read, idempotent), POST (create), PUT/PATCH (update), DELETE (remove).
Return appropriate status codes: 200/201/204 success, 400 client error, 401/403 auth, 404 not found, 409 conflict, 429 rate limit, 500 server error. Include problem+json error bodies with machine-readable codes.
Design for evolution: versioning via URL prefix or Accept header; pagination (cursor preferred for large feeds); filtering and sorting query params; idempotency keys on POST for payments.
Security: HTTPS, auth (OAuth2/JWT), input validation, rate limiting. Document with OpenAPI. Contrast REST with GraphQL and gRPC when interviewers ask trade-offs.
Discussion
Comments (0)
Share how this question came up in your loop, or add tips for others preparing.
Log in to comment on this question.