Theory
Methods and URLs together
FestConnect's backend must let the front end read the event list, add a registration, update a detail, and delete an entry. Each of these is a route: a pairing of an HTTP method (what action) with a URL path (which resource).
The four core methods map neatly to the four basic data actions. This lesson shows how Express defines routes for GET, POST, PUT, and DELETE, how a handler reads parameters from the request and sends a response, and how to keep the logic tidy in controllers. This is the heart of building a REST API.
At a glance
| Method | Action | FestConnect example |
|---|---|---|
| GET | Read data | GET /api/events, list the events |
| POST | Create new data | POST /api/registrations, add a registration |
| PUT | Update existing data | PUT /api/events/5, edit event 5 |
| DELETE | Remove data | DELETE /api/events/5, delete event 5 |
Practical
Defining routes for the four methods
app.get('/api/events', (req, res) => {
res.json(events); // read: send the list
});
app.post('/api/events', (req, res) => {
const newEvent = req.body; // create: data is in the request body
events.push(newEvent);
res.status(201).json(newEvent); // 201 = Created
});
app.put('/api/events/:id', (req, res) => { /* update event :id */ });
app.delete('/api/events/:id', (req, res) => { /* remove event :id */ });This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
Route parameters and query parameters
Requests carry data in two common URL forms.
Route parameters are named parts of the path, written with a colon: in /api/events/:id, the :id is a placeholder. For a request to /api/events/5, Express gives you req.params.id equal to '5'. Use these to identify a specific resource.
Query parameters come after a ? in the URL as key-value pairs: /api/events?category=tech. Express reads them from req.query, so req.query.category is 'tech'. Use these for filters, searches, and options. So route params say which resource; query params refine how you want it.
Practical
Reading route and query parameters
// Route parameter: which event? (/api/events/5)
app.get('/api/events/:id', (req, res) => {
const id = req.params.id; // '5'
res.json(findEvent(id));
});
// Query parameter: filter the list (/api/events?category=tech)
app.get('/api/events', (req, res) => {
const category = req.query.category; // 'tech' (or undefined)
res.json(category ? filterByCategory(category) : events);
});This example runs in Gri-Learn on the web, where you can edit it and see the output.
Quiz
To let the front end DELETE a specific event by its id, which HTTP method and path shape fit REST conventions?
- GET /api/events, because GET does everything
- DELETE /api/events/:id, using the DELETE method with a route parameter for the id
- POST /api/deleteEvent, because POST is for actions
- PUT /api/events, because PUT removes data
Show the answer
DELETE /api/events/:id, using the DELETE method with a route parameter for the id
REST maps the DELETE method to removing a resource, and a route parameter identifies which one, so DELETE /api/events/:id (e.g. /api/events/5) is the conventional shape. Option A misuses GET, which is for READING data, not deleting it (and using GET to change data breaks REST and is unsafe). Option C works technically but ignores REST conventions: the action belongs in the HTTP method (DELETE), not baked into the URL as /deleteEvent with POST. Option D is wrong: PUT is for UPDATING an existing resource, not removing it. Match the method to the action: GET read, POST create, PUT update, DELETE remove, with a route parameter to target a specific item.
Think first
Why let the HTTP method carry the action instead of the URL?
You could name URLs like /getEvents and /deleteEvent. Why does REST put the action in the method and keep URLs about resources? Then tap.
Show the answer
Because separating the RESOURCE (the URL) from the ACTION (the HTTP method) gives a clean, predictable, and standard API, whereas baking verbs into URLs leads to an inconsistent sprawl. In REST, a URL names a THING, /api/events is 'the events', /api/events/5 is 'event 5', and the METHOD says what you want to do to that thing: GET it, POST a new one, PUT (update) it, DELETE it. This means one URL supports several operations through different methods, and any developer can guess the API: to update event 5 they know it is PUT /api/events/5 without consulting a list of custom verb-URLs. The alternative, /getEvents, /addEvent, /deleteEvent, /updateEvent, quickly becomes a jungle of inconsistent names (is it /removeEvent or /deleteEvent? /events/new or /addEvent?), and it wastes the HTTP methods that already exist precisely to express these actions. Using the methods also lets the web's infrastructure help you: GET is understood to be safe and cacheable, DELETE and PUT are understood to change data, so browsers, proxies, and tools behave sensibly. It even improves security reasoning (you never change data with a GET). So REST's discipline, nouns in the URL, verbs in the method, is not pedantry; it produces APIs that are consistent, discoverable, and play well with the web. Resources in the path, actions in the method.
Summary
Key takeaways
- A route pairs an HTTP method with a URL path and a handler function.
- The four core methods map to CRUD: GET reads, POST creates, PUT updates, DELETE removes.
- Express defines them with app.get/post/put/delete(path, handler); the handler gets (req, res).
- Send responses with res.json() or res.send(), and set status with res.status() (e.g. 201 Created).
- Route parameters name path segments (/events/:id, read via req.params.id) to identify a resource.
- Query parameters follow ? in the URL (/events?category=tech, read via req.query.category) for filters and options.
- Memory hook: resource in the URL, action in the method; :id in the path, filters in the query.