This is all downside for no upside. The stated problem to solve -- that it's hard to fit search criteria into query string parameters -- is not really any sort of real problem in practice.
This would have us forgo cacheability, forgo the ability to send a link to a search, introduce more complexity into web servers and clients, all just to be able to send query parameters in the request body.
Pretty sure nobody cares about ensuring that e.g. a proxy knows that nothing will go wrong if it issues a search twice. It's the reverse direction that matters.
I'm surprised not to see this mentioned, but Elasticsearch allows searching over GET with a request body. I believe that GET-with-body is not standard but works great in practice. It allows one to put Elasticsearch behind a proxy that only allows GET, to give customers read-only access.
[edit: or maybe it's standard but not REST-compliant?]
GET requests are indeed not expected to have bodies, and therefore proxies will not always treat them the same way. Some might reject them, others might just pass them through (because in the end GET is also just a verb like everything else).
I wouldn't recommend anyone to rely on it to work - especially not if you are using public/cloud infrastructure.
> 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 it's non-non-standard but not standard either. If I understand correctly a GET with body is about as defined as a POST with body, but since it is not often used the real world support is worse. What is a lot better specified about POST is response codes, like 201 Created and (I'm guessing) content negotiation.
Browsers seem pretty strict about it though, `fetch('/', {body: ''})` gives a TypeError for me but `fetch('/', {body: '', method: 'POST'})` does not.
Counter to some of the other comments (thus far), I'm on board with this as a method.
With the correct header variables, such as Accept-Content, we can settle on nice standardised database querying over the web. Think beyond web pages, and think about proper client-server applications, where the developer doesn't have to re-invent the wheel, or use a framework that may not be in use or supported a few years down the line.
Imagine using curl to do a HTTP SEARCH and piping the response directly into your app or other command line tools. No time wasted developing or installing supporting libraries - it just works.
Edit: Now I think about it, maybe SEARCH is the wrong name. Using SQL as a [bad] example, it would be odd to use HTTP SEARCH to do an insert or update query.
But the method wouldn't actually _do_ anything in your app by itself. If you would want to pipe a SEARCH request's query somewhere directly, that would be up to you in your app to listen for that request method at some url endpoint and send the request body to some data store.
Some people do this sort of thing with sending GraphQL queries to GET routes which may do some validation and then send the query back through. Is there a downside to using GET here?
Are proxies even relevant anymore with HTTPS? The only two scenarios I can imagine are reverse proxies at the server's side (which the server controls), and corporate MITMing firewalls (which I personally think are the plaugue and don't belong in 2021).
A lot of people people use CDN's like cloudflare that MITM your HTTPS to provide geographically based caching (and some other features). That's basically a proxy layer.
I like the concept in general, like a GET w/ data or a cacheable POST, meant to query/retrieve information so you have a semantic distinction for that as well.
17 comments
[ 10.3 ms ] story [ 51.2 ms ] threadThis would have us forgo cacheability, forgo the ability to send a link to a search, introduce more complexity into web servers and clients, all just to be able to send query parameters in the request body.
That was the unique selling point of SEARCH over POST though.
How about using the Range header with a custom value domain instead?
Search is idempotent in the sense that it doesn't change anything on the server, other than mutating caches (which should be idempotent).
[edit: or maybe it's standard but not REST-compliant?]
I wouldn't recommend anyone to rely on it to work - especially not if you are using public/cloud infrastructure.
> 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 it's non-non-standard but not standard either. If I understand correctly a GET with body is about as defined as a POST with body, but since it is not often used the real world support is worse. What is a lot better specified about POST is response codes, like 201 Created and (I'm guessing) content negotiation.
Browsers seem pretty strict about it though, `fetch('/', {body: ''})` gives a TypeError for me but `fetch('/', {body: '', method: 'POST'})` does not.
With the correct header variables, such as Accept-Content, we can settle on nice standardised database querying over the web. Think beyond web pages, and think about proper client-server applications, where the developer doesn't have to re-invent the wheel, or use a framework that may not be in use or supported a few years down the line.
Imagine using curl to do a HTTP SEARCH and piping the response directly into your app or other command line tools. No time wasted developing or installing supporting libraries - it just works.
Edit: Now I think about it, maybe SEARCH is the wrong name. Using SQL as a [bad] example, it would be odd to use HTTP SEARCH to do an insert or update query.
Some people do this sort of thing with sending GraphQL queries to GET routes which may do some validation and then send the query back through. Is there a downside to using GET here?
Also SEARCH was suppose to be case when you don't mutate data, so SQL insert and update is not good usage of it. You should use POST for that.
I don't like it, but it is very common.
I like the concept in general, like a GET w/ data or a cacheable POST, meant to query/retrieve information so you have a semantic distinction for that as well.