As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration. More than one I've seen some sites with UI so bad, that manually editing the url is the easiest way to get it to do what i want.
The HTTP Query Method
31–40 of 136 posts
Re: The HTTP Query Method
#32It’s rare that I have a project that justifies the full DDD treatment, but one of the great ideas from it that stuck with me was command/query separation, where you separate out queries, which can be mangled agglomerations of objects for reporting and lists, from commands, which drive your business logic.
I love the idea of a separate verb. It always felt like get is just not quite enough.
Re: The HTTP Query Method
#33As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration. More than one I've seen some sites with UI so bad, that manually editing the url is the easiest way to get it to do what i want.
Okay, I’m a little confused, the HTTP already supports 8000 octets, and some are having issues because they have too many filters?
Looking at the logs I see that most of the long URI traffic is due to UTM and other tracking related codes, which are mainly a way to work around 3rd party cookie blocks.
I must be missing something, because it sounds like to goal is to have longer URI without the need for encoding URL parameters, but without using POST.
Re: The HTTP Query Method
#34Earlier quoted context omitted.
The problem is that they are not enforced. You can already have GET requests that modify state even though they are not supposed to. What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly. A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has ad…
It would be pretty impossible to actually ‘enforce’ that GETs don’t modify state. I am not sure if I would call the lack of enforcement a problem when it is more a simple fact about distributed systems; no specification can enforce what a service does outside of the what is returned in a response.
That is exactly my point. There is no reason to syntactically distinguish what is semantically non-distinguishable.
The interpretation of a request is up to the server. There is no reason for the client to syntactically distinguish that the request body is for a POST vs QUERY; the request parameters and response have the same shape with the same serialization format.
However, on the other side, a server does control interpretation, so it is responsible for documenting and enforcing how it will interpret. QUERY semantics vs generic POST semantics is a receive/server-side decision and thus should not be a syntactic element of client requests, merely a server description of endpoint semantics (“QUERY endpoint” meaning shorthand for POST endpoint with query semantics).
edit: Thinking about it some more, there is one possible semantic difference which is that a transparent caching layer could use a syntactically different POST (i.e. QUERY) to know it should be allowed to cache the request-response. I do not know enough about caching layers to know how exactly they make fill/eviction choices to know if that is important.
Re: The HTTP Query Method
#35At 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…
A POST could be viewed as creating a "search" which, once given an ID could be retrieved later with a GET.
I know this densest really work with ad-hock and cheap queries but it does for more expensive / report style ones.
Re: The HTTP Query Method
#36A couple of quick observations and comments after skimming through this (some of these are mentioned or hinted at in the RFC). With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY. One of the advantages of GET is the direct visibility, which makes modifications simple and easy for…
The situations where I've wished for GET to be able to have a (typically JSON) body were all in situations where the request isn't "user visible" in the first place. That is: API calls, SPA apps, ajax requests, that sort of thing. Not something people are really supposed to bookmark or call directly. If today you're doing some JS-fu to make an ajax GET request then you already need to do something to have permalinks…
> unless I'm missing something I don't think a QUERY verb will change all that much here?
The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.
Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.
Re: The HTTP Query Method
#37I 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!
I have come across systems that use GET but with a payload like POST.
This allows the GET to bypass the 4k URL limit.
It's not a common pattern, and QUERY is a nice way to differentiate it (and, I suspect will be more compatible with Middleware).
I have a suspicion that quite a few servers support this pattern (as does my own) but not many programmers are aware of it, so it's very infrequently used.
Re: The HTTP Query Method
#38For 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.
If you encounter a shop that uses POST for everything then they are probably a shop that doesn't know that verbs other than GET and POST exist.
... and they don't use GET everywhere because one time Google scraped that endpoint and dropped the production database.
Re: The HTTP Query Method
#39As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration. More than one I've seen some sites with UI so bad, that manually editing the url is the easiest way to get it to do what i want.
Cough Splunk
Also another case is as a dev you are dealing with guids all day and it can be fast to swap guids around in the browser bar vs. ui steps.
Re: The HTTP Query Method
#40Yes! 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.
Most web application servers have already equipped to be able to easily parse parameters out of the URL path for many years, of course, it's definitely nothing new, it's just that historically, people reached for URL query parameters for this sort of thing. After all, making a request with query parameters is basically built into the browser; you can do it with and anchor links with no JS needed.
Presumably, because of that, many pages will continue to use query parameters for the foreseeable future. I think that's fine, but at least for APIs, the QUERY method could eventually be a very nice thing to have.