GET vs POST Request Explained: What's the Difference?

You open a page of API documentation and it just says GET /users and POST /users, like you're supposed to know what that means. Nothing on the page explains why there are two words here instead of one, or what happens if you pick the wrong one. You scroll for an example. There isn't one.

A GET request means "give me information," and it never changes anything on the server. A POST request means "here's information, do something with it," usually to create or change something. Everything else in this lesson is filling in the details of that one distinction.

Key Takeaways

• GET requests read data and have no side effects, you can repeat one safely as many times as you want
• POST requests send data to create or change something, repeating one can duplicate an action
• Every request has a URL, a method, headers, and sometimes a body
• Every response has a status code (like 200 or 404) plus a body, usually JSON
• You can see a real GET response in your browser right now, no code required

---

What Is a REST API?

A REST API is an API that follows a shared set of rules for how requests and responses are structured. You send a request to a URL, with a method that says what you want, and a response comes back with a status code and data.

That shared shape is why you can look at almost any REST API's documentation and recognize the pattern. Without it, every new API you touched would need its own separate tutorial just to get started.

GET vs POST: The Two Ways to Place Your Order

Think back to the waiter analogy from the last lesson. You place an order, the waiter takes it to the kitchen, and a response comes back. GET and POST are the two most common ways of placing that order.

GET means "give me information," and nothing changes on the server because of it. Loading a webpage, checking a weather forecast, or viewing a GitHub profile are all GET requests. You could make the same GET request a thousand times and nothing bad happens. That's why browsers cache GET responses and safely retry them if a connection drops.

POST means "here's some information, do something with it." Submitting a form, posting a comment, or sending a prompt to Claude through the API are all POST requests. This is also the part that trips people up: why not just use GET for everything? The answer is that POST is built for side effects.

Say your browser refreshes a page and silently resends that POST. You could end up submitting the same form twice: two duplicate comments, two duplicate orders. That's exactly why browsers warn you before resending a POST, but never bother warning you about a GET.

What's Inside a Request

Every request you send is built from the same four pieces. Learn them once and API documentation stops looking like a foreign language.

• URL, where the request is going, like api.github.com/users/octocat
• Method, what you want to do, GET or POST being the two you'll see the most
• Headers, extra information attached to the request, like an API key proving who you are
• Body, the actual data you're sending, only present on requests like POST

A GET request usually only needs a URL and a method. A POST request adds a body, since it has something to deliver. When something I've built breaks and the reason isn't obvious, I check the headers first. A missing or wrong API key is an easy thing to overlook.

What's Inside a Response

A response comes back with two parts: a status code telling you what happened, and a body holding the data itself, usually formatted as JSON. Miss the status code and a failed request can look identical to an empty successful one. That's the single most common source of "why isn't this working" confusion for beginners.

Common status codes and what they mean

The full list of status codes is longer than this, but 200, 404, 401, and 500 will cover almost everything you run into as a beginner. The MDN status code reference is worth bookmarking for anything outside that list. The MDN HTTP methods reference covers GET, POST, and the less common methods you'll meet later.

FAQ

Common questions

• Why do we even need POST if GET can technically send data too?

  GET can technically carry a small amount of data in the URL, but it was never meant to change anything on the server. POST exists so there's a method that clearly means "I'm sending you data to act on," with no length limit and nothing exposed in the URL. Browsers and caches also treat the two differently: they'll safely retry a GET, but never a POST, because a POST might have already done something.

• What does a 404 error actually mean?

  A 404 means the server understood your request but couldn't find what you asked for, usually because the URL is wrong or the resource was deleted. It's different from a 500 error, which means something broke on the server's end. If you ever see a 404, the fix is almost always to double-check the URL you're requesting.

• Is it safe to refresh a page that used POST?

  Not always. If you refresh right after submitting a form, your browser may ask if you want to resend the data, because doing so could submit it again. This is exactly why POST isn't safe to repeat automatically the way GET is. If you see that resend warning, it's your browser protecting you from creating a duplicate.

• Do I need to memorize every HTTP method?

  No. GET and POST cover the vast majority of what you'll do as a beginner, reading data and sending data. There are other methods, like PUT, PATCH, and DELETE, for updating or removing things, but you can learn those when you actually need them. Recognizing GET and POST on sight will get you through almost any API documentation.