One rule
Use nouns in URLs. Use HTTP methods for actions.
Your URL says what resource is being touched. The method says what is happening to it.
URLs are addresses
A resource-based URL points to a thing your API manages: users, teams, events, expenses, orders, submissions.
Keep URLs predictable. A teammate should guess the next route without opening five files.
Choose the URL
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Choose the method
The method should match the type of change. This makes your API easier to test with Postman, curl, browser tools, or a teammate’s frontend.
For this lesson, focus on the main four methods you will use in your hackathon repo.
Method map
Use this as your first route list. Change the resource names to fit your project.
GET /api/v1/projects List projects
POST /api/v1/projects Create a project
GET /api/v1/projects/{projectId} Get one project
PATCH /api/v1/projects/{projectId} Update part of a project
DELETE /api/v1/projects/{projectId} Delete a project
GET /api/v1/projects/{projectId}/tasks List tasks in a project
POST /api/v1/projects/{projectId}/tasks Create a task in a project
PATCH /api/v1/projects/{projectId}/tasks/{taskId} Update a task
DELETE /api/v1/projects/{projectId}/tasks/{taskId} Delete a taskCommon mistake
Do not put the action in both the URL and the method. POST /createProject repeats itself. DELETE /deleteProject/{id} repeats itself too.
Prefer POST /projects and DELETE /projects/{projectId}. It is shorter and follows the same pattern everywhere.
Test by reading
Read your routes out loud like a teammate using them during a hackathon demo.
If the sentence sounds like “PATCH one task inside one project”, the route is probably clear: PATCH /projects/{projectId}/tasks/{taskId}.
Do this now
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done