Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
How is this even a question?
GET <- retrieve information
POST -> send information
Unless.... but it's highly unlikely using REST, you need to send data to the server that's not sustainable or practical using query params.
Think SOAP / xml based.
jonas-w5023142dThe Biggest search engines use GET.
There are some privacy respecting search engines which allow you to use POST for searching, this Allows you to not having your search terms in your browsing history.
@C0D4 it wasn't really posed as a question. Someone replied to my PR with: 'using a GET for a search query seems odd to me'.
Imo there are valid reasons to use a POST in some circumstances...
But with POST you lose caching (without extra headers), bookmarkability, good browser back button behaviour and you have to go through the headache of maintaining compatible body models if you're strongly typed
@PeterDCarter Posting a search query doesn't seem right.
Your communicating with an endpoint, a get is asking for data.
You wouldn't ask for data in a post unless the server wasn't following rest best practices.
a post is typically sending it data to deal with, you may get a response.
I can understand using a post if you need to send xml or similar but for rest it's more of an anti-pattern.
@C0D4 possibly would be better for what might otherwise be POST scenarios... I've used OData but not GraphQL, and that's very powerful but sometimes does use POST for complex queries. Does GraphQL always use query string? I can consider a situation where a query can exceed 1000 chars...
It's not what I'm doing atm: the person posted as a response to a simple endpoint with a query string and a max matches parameter, which is tied to an external service that's unlikely to change much. I just like to seek additional opinions (where practicable) before calling someone out on something if there may be additional angles I didn't consider.
Oktokolo9062142dIn addition to the general rule of using POST for alteration and GET for retrieval, you also need to use POST when doing retrieval protected by a CSRF (cross site request forgery) prevention Token.
Normally you wouldn't protect data retrieval that way. But if log read access, you definitely should.
PeterDCarter292141d@realngnx "The GET request means retrieve whatever data (in the form of an entity) is identified by the Request-URI" -- Source: W3C RFC 2616
Yes you can do it but it still kinda violates the spec (depending on if you read the above as exclusive) and it might not work with your libraries etc and/or cause problems with other integrations down the line...
PeterDCarter292141d@realngnx it says the retrieved data is identified by the URI. Implication is by that exclusively. Why would you include a body in a GET if not to help identify what data you want? And if the job of the URI is to identify the data, what's the body doing?
All things may be permitted, but if you invoke W3C are you not judged by the invocation?
theabbie8168141dGET obviously, it will also log in browsing history which is expected behaviour.
C0D470561141dif it's not in the spec, it's an anti pattern to the spec, so long as you follow the spec that is.
Or to put it another way:
A GET with a body is like a dildo with a condom.
It's not expected, but I'm sure someone feels better for it.