REST APIs
Before you choose URLs or status codes, decide what things your API manages. These things are resources.
A resource is usually a noun your teammate can point to: student, event, team, payment, submission. It is not an action like register, pay, approve, or search.
Design the API around resources, not screens or buttons. Actions usually become changes to a resource, or creation of a related resource.
0 of 8 lessons done · proved by a submitted project with a public repository
Imagine you are building a college hackathon API. A beginner might list features like this: create event, register team, approve project, view submissions.
Now rewrite them as resources. This gives you a cleaner base for routes later.
Feature idea -> Resource
create event -> events
register team -> registrations
approve project -> projects or reviews
view submissions -> submissions
add team member -> team_members
track UPI payment -> paymentsDo 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
Do not start with routes like /createEvent, /doPayment, or /getAllTeams. These describe functions, not resources.
Your repo will look more professional if the API feels like a model of the real system, not a list of button clicks.
You can ask ChatGPT, Gemini, or Claude to extract resources from your app idea. Do not accept the first list blindly.
Check if each item is a real thing your API stores or returns. Remove vague words like data, info, record, manager, and service.
Prompt:
I am building a REST API for a college hackathon project.
App idea: Teams register for events, submit projects, judges review submissions, and organisers publish results.
List the main API resources as nouns.
For each resource, say what it represents.
Avoid actions, screens, and UI terms.A resource map is a small planning file. Add it to your repo before coding. It helps a teammate understand your API shape quickly.
You can name it API_PLAN.md or RESOURCE_MAP.md.
API resource map
App: Campus hackathon manager
Resources:
- users: students, organisers, and judges who log in
- events: hackathons or coding rounds hosted by the college
- teams: groups of users who participate together
- registrations: a team joining an event
- submissions: project links submitted by teams
- reviews: judge feedback and scores for a submission
- payments: optional fee payment records, if the event charges in rupees
Not resources:
- dashboard: this is a screen
- registerTeam: this is an action
- getWinners: this is a query or result view, not a core stored thing yetDo 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
Answer the quick check to finish this lesson.