Making GET requests have bodies as the norm would also handle this
I suspect the challenge would be all the middleware that assumes that get never had a body.
The HTTP Query Method
21–30 of 136 posts
Re: The HTTP Query Method
#22Earlier quoted context omitted.
I'm confused - wouldn't idempotent POST be PUT? Isn't the proposed QUERY for fetching semantics?
I think the idea is that POST creates a record (and in theory fails if that record already exists). I guess the commenter above is saying that if you inverted that (fail when the record doesn't exist, return the record if it does) it would be similar to QUERY? Not sure if I agree with that, but PUT's return semantics are a bit vague.. it often returns partial or combined records, or just a 200 OK (with or without a r…
PUT is the idempotent one. POST typically performs an action; PUT just creates-or-updates.
Re: The HTTP Query Method
#23We already have POST, PUT, and PATCH that do the exact same thing. Why not have another version of GET that looks the same as POST and is subject to personal interpretation. FYI: QUERY is for GET requests where the query string make the URL too long. It does this by sending a body like POST. In the past, POST meant you were sending a body, and GET meant you received a body. And the people got religious about a pseudo…
The point of the HTTP verbs is to communicate expected behavior. While a server could treat POST, PUT, and PATCH the same, the point of having the verbs at all is to give a standard way to signal clients what is going to happen. While a server can ignore the expectation, it doesn’t mean the expectation isn’t valuable; it allows conforming implementers to communicate what is happening using standard language.
Re: The HTTP Query Method
#24Making GET requests have bodies as the norm would also handle this
or get requests with query params already handles this in majority of the cases, unless the query size is too big (which ideally should not be the case since in the end it is a get request)
Re: The HTTP Query Method
#25At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet.
The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implemented as a POST endpoint, despite it being an idempotent query for data, since the request body is too large to fit in query parameters. New employees repeatedly come in and are confused why it’s not a GET endpoint, or why it doesn’t modify anything.
Re: The HTTP Query Method
#26I can’t wait for QUERY to become an official RFC. It's felt quite awkward to tiptoe around the existing spec when building features that retrieve data; we've had to either use POST to keep sensitive filter criteria out of http logs or just create a usually massive URL-encoded query string.
Very timely as I just recently ended up with a URL query string so big that CloudFront rejected the request before it even hit my server.. Ended up switching that endpoint to POST. Would've liked QUERY for that!
Re: The HTTP Query Method
#27Yes! This sounds like a great idea to me. It does have some trade-offs, but I think we would've been better off with this than ever having put queries in the URL in the first place. Rather, if it made enough sense to have some data in the URL itself, it would be better if it could actually be in the path , to distinguish it as a distinct resource. I think there are many reasons why this didn't work out that way but I…
> I would prefer things like /map///, for example.
PathInfo is a thing you can absolutely use.
Re: The HTTP Query Method
#28Does anyone know what blocks something like this being accepted? I’ve had my eye on this for ages and have had to work around its lack multiple times, so just curious what the hold up could be.
Re: The HTTP Query Method
#29For the experienced devs. May I ask why would one use POST for everything?
I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.
Re: The HTTP Query Method
#30At this point I’m infamous in my company for complaining about how something should have been done with a QUERY verb but it hasn’t been approved yet. The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implem…
Also cases where a GET makes more sense, but there is concern about sensitive data in query parameters getting exposed in logs, so POST is used instead.