Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@MrCSharp long ass amount of filters for example, browsers have also limitations on how long a query string can be, if your point is about putting everything in query parameters, have fun with when it doesn't work because of browsers
-
@PrivateGER Depends
In most descriptions GET is far fetching data with no side effects and POST is for creating data.
With this definition, if you need to send large filters to a search that do not change the state of the server, you should use GET and if the query string is to small, use a payload.
So I agree with OP that switching to POST for a search is wrong as it implies that you expect side effects. -
@Voxera @nitwhiz @PrivateGER I would also add that it's up to the context to choose between GET and POST, some calls make more sense if they are GET even with body, some calls make more sense as POST.
-
@Voxera that makes sense. I hate that it makes sense.
-
@MrCSharp I can see a complex odata query with subselections growing ;)
It’s not necessarily a good question ;)
But it is possible. -
Is there a way to have a JavaScript-less HTML5 form use GET with a fixed payload and still have all the other fields in the URL query string?
That would allow to add CSRF prevention tokens to GET forms while still keeping them linkable (the server would generate the prefilled form when the token is missing). -
@Voxera complex OAuth and OpenId info, tokens, signatures + custom application state gets passed in GET requests via URLs. I reckon if the global authentication and authorization standards are using query strings for that, search can use it too. I'm finding it hard to beleive you'd need even 1MB of filters for a search endpoint.
I'm not arguing in bad faith here as I am very netrual to this argument. I haven't spoken to someone who holds your opinion so i am trying to understand it more. -
@MrCSharp well, the query string is in reality limited to 2000-4000 chars due to browser limits, not 1Mbyte.
And I also think that most usage will fit within this limit, but I just took some example that could potentially be to much.
HTTP response code cheat sheet
(From /r/Programmer humor)
GET Requests with a BODY as a payload are legit and stop living in denial!
TALKING TO YOU ANGULAR!
I'm fucking sick of seeing ignorant people(on SO or GitHub) coming up with the generic advice, on HTTP GET issues with having a BODY as a payload, to don't do that or you shouldn't, yadayadayada.
It's not a fucking issue at all in general, because as RFC-7231(https://tools.ietf.org/html/...) sais:
"A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."
So, if your fucking server can't handle them(aka living in the past), [rest] in peace and suck it up!
(ps, I happen to use modern servers)
But why should you limit a fucking front-end framework(ex. Angular) in the first plate to being able to send such requests?!
It's a moronic limitation and the person or team responsible for it are at least clueless and as far the issue has reappeared through time, for how old is Angular, they didn't move an inch.
rant
angular
rfc-7231
front-end
get
body payload
http
server