When to make GET vs POST requests
Posted by DisciplineFast3950@reddit | learnprogramming | View on Reddit | 27 comments
I'm wondering if the "intent" of the request matters whether a fetch request should be GET or POST. Obviously if you're sending a json payload it has to be POST but I also heard that POST should be used when the request is intended to modify or change something on the backend/server, and GET should be used when simply fetching data. So if I'm pinging a very simple endpoint for example mysite.com/endpoint which starts a process on my server but doesn't need a json payload the request should still be a POST request?
SnooChipmunks547@reddit
GET: I want some data.
POST: here’s some data for you
PUT: here’s some data, replace what you have already have.
PATCH: here’s a little bit of data, update what you have
DELETE: I don’t want you to have this data anymore, almost always a soft delete not a hard removal.
DisciplineFast3950@reddit (OP)
Nice 👍
HealyUnit@reddit
This is a major oversimplification, but you can kind of think of GET, POST, PUT, and DELETE requests as corresponding to the four "CRUD" (Create, Read, Update, Delete) operations you can perform on a database, as follows:
Support of JSON bodies for GET and DELETE requests is inconsistently supported, so it's probably best to avoid.
So to directly answer your last question, it's... not 100% clear. If I call
myserver.com/myApi/toggleBigRedLight, and that request has no actual data input, should that be a GET (since it has no data), or a PUT (since I'm updating)? Personally, since you are asking for the server to change something, I'd suggest using PUT here.iamnull@reddit
I would say PATCH for update. PUT is more often used for create or replace.
HealyUnit@reddit
That's fair. I guess I just wanted to differentiate between POST - which I've often seen as "make brand new" and... whatever you use to "update".
As clearly illustrated by the replies here tho, u/DisciplineFast3950, the answer on what to use varies widely
zeekar@reddit
PUT creates or replaces a thing that you have the full name of (URI path).
POST creates a new thing by generating part of its URI path - like assigning an ID number.
So if you already know that the thing you're creating is to be /things/123, and you don't mind replacing any existing /things/123, you do PUT /things/123. If you just want to create a new thing and let the server pick its number, you do POST /things and the reply tells you the id.
hitanthrope@reddit
Others have pointed this out but I want to amplify.
Post = create, Put = update is a very common but I think quite wrong simplification.
Idempotency is the core idea but PUT is more or less what the verb means. “Take this thing and place it here”.
Really if you do a PUT on a url and then a GET you should GET the exact thing you PUT. That’s very purist obviously and exceptions can be made, but what doesn’t matter is what was there before. Could be a create or an update.
It’s really like, GET, PUT and DELETE are your three main state functions and POST is more like, “here’s something you might want to do something about… but it’s up to you”.
DisciplineFast3950@reddit (OP)
Thanks for your detailed response. I've never actually used PUT or DELETE .. they loosely fall under the umbrella of POST. I wonder if all of these request parameters will stand the test of time or if some of them are slowly falling into obsolescence.
HealyUnit@reddit
Yeh, when I was starting out at my current job, I'd do the same thing. The point, I think, isn't that you have to use the exact right verb for each request, but rather that you have some sort of system. So if that's "I use PUT for updates", or "I use POST for updates" or "I use PATCH for submitting anything that rhymes with 'dog', and UPDATE for everything else", it's far better to have a specific system than to just go "...Yeh, lump everything under POST".
DisciplineFast3950@reddit (OP)
Definitely. Part of the evolution of the programmer I guess. We start out GET and POST'ing everything and later become more nuanced and take a greater interest in actually RTFM haha. Definitely gonna start upping my http semantics.
TheRealKidkudi@reddit
Ignoring that this would be a terrible API design, this would be POST because a toggle is not safe or idempotent. I suppose it could also be PATCH.
PUT, on the other hand, is better to think of as “replace” than simply “update”. Sending the same PUT request twice should result in the same state that you’d get from sending it once, whereas a toggle wouldn’t - the first time would turn it off, and the second would turn it back on (or vice versa)
PurrNaK@reddit
Put and lost are interchangeable in most api's since you can combine a create, then update in the same transaction. Get should be read only. Delete is a hard slap to knuckles. Post null, do not delete. Unless its your own interface or you have restrictions on delete access.
smerz-@reddit
Imho a GET should never alter state or start a process or so. Or in other words a GET should always be retryable without consequences.
Outside_Complaint755@reddit
It also should never include anything possibly sensitive in the request. If your get request includes something like
?userid=8473&api_key=egH837Ns93sWvd, you're definitely doing something wrong.Fant1xX@reddit
this can be perfectly fine, what's your issue?
ehr1c@reddit
You're right, but it can also be a security risk if it's not implemented properly. I.e. non-HTTPS requests, poor logging/telemetry practices, etc
Fant1xX@reddit
these could all affect POST bodies as well, so there's nothing uniquely bad about putting sensitive data into the query params
ehr1c@reddit
It's pretty common for request URLs to end up in logs or telemetry traces, it's a lot less common for request bodies to end up there.
HoneydewAdditional30@reddit
Usually GET is read only data (so you simply retrieve data) and POST is used to send data or update it. The there is PUT for updating or replacing data and DELETE (self explanatory).
HOWEVER, what many don't mention is that REST is not a set in stone rule but guidelines for orientation. Meaning it is good to be as restful as possible but ultimately it really depends a lot on the specific API and how it was implemented. For example sometimes PUT is used over POST and vice-versa.
huuaaang@reddit
GET - Doesn't mutate data, just... gets.
POST - Creates new data
PUT - Mutates/replaces whole units of data
PATCH - Partially mutates unit of data
DELETE - Deletes units of data
DirtAndGrass@reddit
If you are intending to be restful, you should follow the standard mappings
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods
TheRealKidkudi@reddit
OP, this is your best answer. This isn’t something you have to take some Reddit comment’s word for; there is a clearly defined spec for HTTP methods.
MDN is a great resource for this, and I’d encourage you to start there as you continue to learn. They have thorough docs for just about every web standard out there and it’s going to give you much better information than random Redditors/blog posts/SO answers/whatever else you’ll find Googling.
dumpin-on-time@reddit
get, head, option should be idempotent.
post, put, patch, and delete are not. post creates. patch and put update. delete deletes
the rest are probably unlikely used
post is also used for transmitting sensitive data
TheRealKidkudi@reddit
All of them are expected to be idempotent except POST and PATCH.
Idempotent does not mean a request makes no changes on the server. It means that it has the same intended effect whether an identical request is sent once or multiple times.
In other words, idempotent requests only need to be delivered “at least once” (retries are OK), whereas non-idempotent requests need to be delivered “exactly once” (retries are not OK)
dmazzoni@reddit
I think it's important to draw a distinction between rules that are conventions, and rules that will actually impact whether your software works correctly or not.
Let's take the browser as an example. If you fetch a url using GET, the browser will assume that it's safe to call twice if the first one failed, and that it's safe to cache and reuse. It's assuming that it's "idempotent" and has no side effects.
So that's why you wouldn't want to use GET to perform an action - even if you only access the url once, a browser isn't going to assume it performs an action, it assumes it's just fetching a resource - and so it might call your backend the wrong number of times.
Similar issues happen when there are proxy servers, load balancers, or crawlers - they all assume that GET requests are "safe" to cache or fetch again, but POST requests are not.
GeneralBarnacle10@reddit
The biggest thing is that GETs should absolutely be idempotent, which means you can run the same thing multiple times in a row and nothing changes. Crawlers depend on this. They assume they can execute a GET and never mess anything up.
If something kicks off because of the request, then you need to be okay if this kicks off multiple times. If it's like a counter or something, that should be okay and makes sense if you're trying to count something. If it's a longer running process, then a POST would probably be better.
Asleep-Party-1870@reddit
POST is create a resource GET for getting it, or getting an existing resource on a server