Concept explanation
Backend APIs become easier to learn and maintain when their routes describe resources cleanly. This game turns common product requirements into method and route choices.
All games
API Route Builder
Design REST-style methods and routes for product requirements such as creating users, updating email, searching products, and nested comments.
- Concept
- REST API route design
- Difficulty
- Beginner
- Play time
- 6-9 minutes
- Path
- Foundations
practice/api-route-builder Route design score Play, get feedback, save local progress, and optionally submit a leaderboard score.
Playable game area
Use the controls below. Feedback appears immediately, and final scores are stored locally.
Leaderboard
Top 10 submitted scores. No account required.
Loading leaderboard...
Finish the game to load your latest local score.
Learning objectives
- Choose HTTP methods based on intent and idempotency.
- Model resources with nouns, route parameters, and nested relationships.
- Avoid action-heavy routes when a resource-oriented design is clearer.
How to play
- Read the backend product requirement.
- Pick the HTTP method and route that best model the resource change or read.
- Submit your design to see the explanation and move forward.
Scoring
- A correct method and correct route earns full points.
- A correct method with the wrong route earns partial learning feedback but no full score.
- Final score rewards consistency across the full route set.
Backend concept notes
REST route design is about making resources and state changes predictable. Clients should understand the shape of the API without memorizing many custom verbs.
Routes are not only syntax. They encode ownership, scope, cacheability, and the difference between replacing a resource and partially changing it.
Common mistakes
- Using GET for state-changing operations.
- Putting verbs everywhere, such as POST /createUser, when POST /users is clearer.
- Forgetting nested ownership, such as comments that belong to a post.
FAQ
Short answers for how this game fits backend interview and study practice.
Are action routes always wrong?
No. Some domain actions are clearer as action subresources, such as POST /orders/:id/cancellation. The key is to be intentional.
Should search use GET or POST?
Simple queryable searches usually fit GET with query parameters. Very complex searches can use POST to a search resource.