11–20 of 79 posts
The spec doesn't say how browsers should represent such request in the browser address bar. The nice thing with GET is that you can copy a search url, bookmark it or share it with someone, and they get back the exact same results. How would that work with a QUERY method?
- why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action.
- QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string
Is GET with a request body impractical at this point? It has historically been frowned upon [1] but is it really too late to change that convention? [1]: https://stackoverflow.com/questions/978061/http-get-with-req...
But it does lead to unexpected behavior. Users are trained to copy/paste links and send them. If the body only included stuff like auth tokens then it would be ok, but if relevant query stuff was in there (like page size, for example) that would lead to different results that would ultimately be deleterious IMHO.
The spec doesn't say how browsers should represent such request in the browser address bar. The nice thing with GET is that you can copy a search url, bookmark it or share it with someone, and they get back the exact same results. How would that work with a QUERY method?
I hope this does not mean that this will be taken as the default method of querying.. A JSON query object could've been nice as an example.
How should you handle conflicting parameters (form-encoded + body)?
Also, on the HTML side.. If it's extended to .. how will you be able to distinguish between the query part and the uri part?
How can/should you copy/share links? Will browsers simply base64 encode this somewhere?
The spec doesn't say how browsers should represent such request in the browser address bar. The nice thing with GET is that you can copy a search url, bookmark it or share it with someone, and they get back the exact same results. How would that work with a QUERY method?
However, just as with POST requests, it might make sense for the server to respond with a redirect to a URL that could be shared.
Two things that come to my mind: - why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action. - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as que…
Two things that come to my mind: - why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action. - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as que…