5 ms·

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

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?

detaro 5y ago
same as with POST: not really intended for that case.
wwosik 5y ago
probably same as with POST, that is not at all
jdlshore 5y ago
The browser address bar performs GET requests, so I think the answer is "you can't bookmark or share QUERY requests," same as with POST requests. 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.
zamadatix 5y ago
I'm not sure it makes sense for an HTTP protocol method standard to describe how browsers should allow it's input in the URL bar - two very different standards realms. That said you should be able to trigger any custom HTTP request your browser support via pasting/bookmarking a `data:` or `javascript:` construction if you really want. As of now the URL bar is GET only when you enter a URL.
- hakre 5y ago
  > I'm not sure it makes sense for an HTTP protocol standards to describe how browsers should allow it's input in the URL bar - two very different standards realms. Just as a small remark, HTTP protocol standards do - or have at least - considered URL input so far in a wider, client-side meaning. Some details are left for the clients, e.g. it differs across browsers how certain URL characters are interpreted when entered into the URL bar (or on the command-line, e.g. with curl(1)). Apart from that, HTTP URLs are part of the same HTTP standard, aren't they?
  - deleted 5y ago
    [deleted]
  - zamadatix 5y ago
    HTTP URLs and HTTP methods are two very different things, somewhat conflated in that the browser treats URLs in the URL bar as a shorthand for generating a GET. While URL encodings are well standardized for general use in RFCs the parsing into an HTTP GET when entered into the URL bar is not, it's just good UI. The same would be said about the QUERY method standard, it's not about describing how the browser UI should allow making such a request header just what a valid one is.
aabbccsmith 5y ago
It's more for the SPA age of web apps, where we want to GET a resource from an API, but have a body in the request. For example fetching the user who is currently logged in and getting a JSON response back; it's not something you would do in the address bar.
capableweb 5y ago
Similarly to as if you were using POST requests I'd say. So if you want the users to be able to navigate to a URL and get the same results for a POST request, you'd make the client-side read URL parameters and sculpt the POST request and send it.
bityard 5y ago
In HTTP, clients are user agents and a web browser is only one kind of user agent that is specialized in fetching and displaying web pages. Like PUT and DELETE, this is clearly meant for APIs, not web pages. (Although sufficiently "advanced" web pages may make API calls.)

detaro 5y ago

same as with POST: not really intended for that case.

wwosik 5y ago

probably same as with POST, that is not at all

jdlshore 5y ago

The browser address bar performs GET requests, so I think the answer is "you can't bookmark or share QUERY requests," same as with POST requests. 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.

zamadatix 5y ago

I'm not sure it makes sense for an HTTP protocol method standard to describe how browsers should allow it's input in the URL bar - two very different standards realms. That said you should be able to trigger any custom HTTP request your browser support via pasting/bookmarking a `data:` or `javascript:` construction if you really want. As of now the URL bar is GET only when you enter a URL.

hakre 5y ago
> I'm not sure it makes sense for an HTTP protocol standards to describe how browsers should allow it's input in the URL bar - two very different standards realms. Just as a small remark, HTTP protocol standards do - or have at least - considered URL input so far in a wider, client-side meaning. Some details are left for the clients, e.g. it differs across browsers how certain URL characters are interpreted when entered into the URL bar (or on the command-line, e.g. with curl(1)). Apart from that, HTTP URLs are part of the same HTTP standard, aren't they?
- deleted 5y ago
  [deleted]
- zamadatix 5y ago
  HTTP URLs and HTTP methods are two very different things, somewhat conflated in that the browser treats URLs in the URL bar as a shorthand for generating a GET. While URL encodings are well standardized for general use in RFCs the parsing into an HTTP GET when entered into the URL bar is not, it's just good UI. The same would be said about the QUERY method standard, it's not about describing how the browser UI should allow making such a request header just what a valid one is.

aabbccsmith 5y ago

It's more for the SPA age of web apps, where we want to GET a resource from an API, but have a body in the request. For example fetching the user who is currently logged in and getting a JSON response back; it's not something you would do in the address bar.

capableweb 5y ago

Similarly to as if you were using POST requests I'd say. So if you want the users to be able to navigate to a URL and get the same results for a POST request, you'd make the client-side read URL parameters and sculpt the POST request and send it.

bityard 5y ago

In HTTP, clients are user agents and a web browser is only one kind of user agent that is specialized in fetching and displaying web pages. Like PUT and DELETE, this is clearly meant for APIs, not web pages. (Although sufficiently "advanced" web pages may make API calls.)