GET, POST and the other methods

What does the method in a request mean?

The method is the first word of every request, and it says what the client wants to happen. The path says which thing; the method says what to do with it. GET /bookings asks to read the bike shop’s bookings. POST /bookings asks to add one. Same path, different intent.

HTTP defines a handful of methods, and five cover nearly everything a website or API does. Each has an agreed meaning, and browsers, caches, search crawlers and other tools all rely on servers respecting it.

• GET reads something and changes nothing.
• POST sends something new, such as a booking or an order.
• PUT replaces a whole thing with the version sent.
• PATCH changes part of a thing, such as one booking’s job.
• DELETE removes a thing.

How do you write a route for each method?

Express gives you one function per method: app.get(), app.post(), app.put(), app.patch() and app.delete(). Each takes a path and a handler, exactly like the app.get() routes you have written so far. A route only answers requests with its own method.

That means one path can have several routes, one per method, each doing a different job. The bike shop’s /bookings path reads the list for GET and adds to it for POST. When a request arrives with a method that has no route for that path, Express answers 404 with “Cannot POST /bookings” or the matching method name.

There is also app.all(), which matches every method. It is handy for a page that must answer the same way to anything, and rarely the right choice for routes that change data.

app.get('/bookings', (req, res) => {    // read the list
  res.json(bookings);
});

app.post('/bookings', (req, res) => {   // add one
  bookings.push(req.body);
  res.json(bookings);
});

Why does a link or the address bar always send GET?

Typing an address, clicking a link, loading an image or a stylesheet: all of these send GET. Browsers treat reading as the default because it is harmless. A plain HTML form also sends GET unless you write method="post" on it.

To send any other method, something has to ask for it on purpose. A form with method="post" sends POST. JavaScript’s fetch() can send any method. Tools such as the request bar here let you pick one from a menu. HTML forms only know GET and POST, so PUT, PATCH and DELETE come from fetch() calls and from programs talking to an API.

This is why the Browser view can only send POST /bookings once a page has a form or script for it. Use the request bar: choose POST, type /bookings, pick JSON, and enter a body.

Where does the data in a POST come from?

A GET carries everything in its path and headers. A POST, PUT or PATCH usually carries a body too: the new booking, the changed price, the filled-in form. The Content-Type header says what format the body is in, such as application/json.

Express doesn’t read bodies on its own. app.use(express.json()) near the top of the file adds a step that reads JSON bodies and puts the result in req.body. Without it, req.body is undefined in Express 5, and your route stores nothing without any error. Form posts need express.urlencoded() instead, which the forms lesson covers.

Press **Book a repair** and open “Headers and body”. You will see the body as JSON text and the Content-Type header that told express.json() to parse it.

POST /bookings HTTP/1.1
Content-Type: application/json

{"bike":"Blue road bike","job":"Puncture repair"}

What do safe and idempotent mean?

These two words come up whenever people discuss methods, and both have plain meanings. A safe method doesn’t change anything on the server. GET and HEAD are safe. Anyone can send them any number of times and the bookings stay as they were.

An idempotent method can be repeated with the same result as sending it once. PUT is idempotent: replacing a booking with the same data twice leaves one booking with that data. DELETE is idempotent too: deleting booking 7 twice still ends with booking 7 gone. POST isn’t: sending the same booking twice creates two bookings.

That difference shows up in real life. Browsers warn before resending a form after a refresh because it was a POST. Network tools may retry a GET or PUT that timed out, and they won’t retry a POST on their own.

Why must GET never change data?

Programs you don’t control send GET requests all the time. Chat apps fetch links to build previews. Some browsers load likely next pages early. Search crawlers follow every link they find. If GET /bookings/clear empties the list, any of them can do it, and you will never know who did.

The rule is simple: if a request adds, changes or removes something, it uses POST, PUT, PATCH or DELETE. A “Clear the list” button on a staff page should be a small form with method="post", or a fetch() call with the right method, never a link.

This also protects you from a class of attacks where another site tricks a logged-in visitor’s browser into opening one of your links. The cookies and security lessons build on it.

Which method should a new route use?

Ask what the request does to your data. Reading anything, a page, a list or one item, is GET. Creating something whose address the server decides, such as a new booking, is POST. Changing one field of an existing booking is PATCH. Replacing the whole booking is PUT. Removing it is DELETE.

Many small sites only ever use GET and POST, because that is all plain HTML forms can send. That works. APIs called from scripts tend to use all five, which makes their routes easy to read: the method tells you the action, and the path tells you the thing. The API lessons later in the course build a full set for the bakery menu.

What should you check when an AI writes these routes?

Look for routes that change data on GET, such as /delete/:id or /clear links. Check that every route which reads req.body has express.json() or express.urlencoded() set up above it. And compare each route’s method with the one the form or fetch() call actually sends, since a PUT route paired with a POST form is a common slip.

AI tools also like to invent paths such as /bookings/add, /bookings/delete or /updateBooking where the method already says the action. They work, but they hide what a request does behind a name, and a GET to /bookings/delete is exactly the kind of link a crawler will follow. Prefer one path per thing and let the method carry the verb.

Then send each request from the request bar with the right method and body, and watch the Requests view name the route that handled it.

Field notes

• The method says what the request wants to do, and the path says which thing.
• Express has one function per method, such as app.get() and app.post().
• Data sent with POST arrives in the request body, which you read from req.body.
• A GET request should only read data, because many programs send GET on their own.

Easy to get wrong

Links always send GET, and many programs follow links on their own. Anything that changes data belongs behind POST or another non-GET method.

Express needs a body parser before it fills in req.body. Add express.json() once, above the routes that read JSON.

Routes match the method as well as the path. A POST request skips a PUT route and ends in a 404.

Questions people ask

Can an HTML form send PUT or DELETE?

No. HTML forms only send GET and POST. Pages that need PUT, PATCH or DELETE use fetch() in JavaScript, which can send any method.

What is HEAD?

A HEAD request asks for the same headers a GET would get, without the body. Express answers it with your GET route automatically and leaves the body out.

What is OPTIONS?

Browsers send OPTIONS to ask which methods and headers a server allows, mostly before cross-site requests. The CORS lesson covers it. A real Express app answers an unhandled OPTIONS request with an Allow header listing the methods it has routes for; the practice server does the same, and you can try it by choosing OPTIONS in the request bar.

Is POST more secure than GET?

Only a little. A POST body doesn’t appear in the address bar, browser history or server logs the way a query string does, so passwords should never go in a GET. Both travel in plain text without HTTPS, and both can be sent by anyone.