One of the user cases listed - being able to send a large body of data to a server for it to encrypt (though it could be any sort of transformation, e.g. reformatting, encoding, format conversion, or even operations like "spell check" etc.) strongly suggests to me we don't need a new verb, but should simply redefine the expected behaviour for GET requests for when they do or don't have a body - even if it means there's a expectation and method for clients to first query servers whether they have that ability (as servers that don't support "search" will return an error if that verb is used, whereas servers, esp. proxies/load balancers etc, may well simply ignore the body if GET is used.).
And to not define caching semantics seems somewhat crazy - it's bound to result in implementations inventing their own (the obvious one would be to combine some hash of the body with the URL to uniquely identify the request).
Defining a new HTTP method: HTTP Search (2021)
101–110 of 131 posts
Re: Defining a new HTTP method: HTTP Search (2021)
#102Another way to think about it, if you're doing REST as it seems the author of this article seems to strive for is to introduce a "search resource". You'd then POST to e.g. POST /searches with the query in the body, and on the server side a search resource is created. The server performs the search query and returns the result with a search ID. To do the same search again just do a GET /searches/ID.
Re: Defining a new HTTP method: HTTP Search (2021)
#103One advantage of GET is I can just copy the URL and share it. The article makes no mention of that. While I love the proposal (apart from the name, I can see the SEARCH verb being used for something that's not search), they should also address the URL share-ablity aspect. Something like " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…
> One advantage of GET is I can just copy the URL and share it.
Often but not always.
The article is wrong when it says message bodies for GET are defined to be meaningless. They are in fact just not defined to be meaningful, which is very much not the same thing.
Nothing in the spec for GET blocks using message bodies with it. Elastic search famously uses(used?) bodies with GET requests.
Re: Defining a new HTTP method: HTTP Search (2021)
#104Right now, you have two main options: Use a GET, and squeeze all the parameters you need in the URL or headers somewhere Use a POST, and have the request considered as unsafe & uncacheable Third option: you POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached. Wanting a special method for search hurts the conceptual integrity of HTTP, whe…
That's exactly what we do: submitting a search/filter form through a POST request which creates a record in the database representing the search/filter criteria and then redirects to the same endpoint with the ID of that record. The endpoint looks for the ID in the query, attempts to load the same record, and if found, executes and returns the search results. It works very well, is completely transparent to the end u…
I really wish I'd thought of this method when I was building a search based application. It was my first time and I struggled with structuring everything
Re: Defining a new HTTP method: HTTP Search (2021)
#105> GET requests ... can't have a request body. It's not specifically banned, but it is defined as being completely meaningless
This is widely believed but false. And repeating it leads me to believe that the author is not careful enough to create new standards. They are just not defined to be meaningful, which is not the same thing.
In fact the standard says that sending a message body with a GET request should not (specifically SHOULD NOT, not MAY NOT) be done unless you have confirmed that the servers accept it, because servers are not required to accept it, but that if you are talking to a server directly that you know supports it then it's perfectly fine and within the standard.
Re: Defining a new HTTP method: HTTP Search (2021)
#106What if modern browser support advanced URL bar with POST method ? (Like Postman UI)
This new method would be idempotent and safe. POST is neither.
But, adding other methods than GET to the address bar in browsers is an interesting idea. It'd affect such a small percent of people it'd most likely be a net time sink than time saver, though.
Re: Defining a new HTTP method: HTTP Search (2021)
#107Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
It sort of does, but support is spotty. I've tried using it only to have things like MITM proxies on my customers' corporate networks drop the body. It'd be a large push to get universal support. It may be more difficult than simply adding a new method.
But if a new method is needed, servers have to support it (e.g., by updating them to the next version that supports the new method). In the same sense, couldn’t that new version “just” not drop the body of GET requests?
In any case we are talking about updating servers.
Re: Defining a new HTTP method: HTTP Search (2021)
#108Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
You can actually do that already. It's one of those things where the specification is a bit loose on this. Elasticsearch is an example of a product that supports doing a GET with a body to do search. Works fine but not all http clients allow you to do this so they also support POST.
Nice discussion on HTTP GET with a body here: https://stackoverflow.com/questions/978061/http-get-with-req...
TLDR. the http 1.1 spec was a bit vague on this and allowed people to send a body but specified that servers should ignore that if they did. Later updates of the 1.1 spec removed that sentence and actually allow this. The caveat that the spec mentions that some implementations may not support it.
So an update is not needed; it's already allowed.
I tend to not get too hung up on the meaning of http verbs. I sort of lost interest in the endless debates on this years ago. I like a well designed REST API of course and I try to follow the principle of the least amount of surprise when I implement one myself. Using exotic new experimental http verbs would be surprising. Using GET this way is also a bit surprising. I actually steer clear of using PATCH as well. Just use a PUT or a POST and move on.
Adding new verbs to HTTP is redundant as far as I'm concerned. Not really against it but where does it stop? And what do we get out of it? It doesn't sound like it's worth the trouble.
Re: Defining a new HTTP method: HTTP Search (2021)
#109One advantage of GET is I can just copy the URL and share it. The article makes no mention of that. While I love the proposal (apart from the name, I can see the SEARCH verb being used for something that's not search), they should also address the URL share-ablity aspect. Something like " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…
> One advantage of GET is I can just copy the URL and share it. Often but not always. The article is wrong when it says message bodies for GET are defined to be meaningless. They are in fact just not defined to be meaningful, which is very much not the same thing. Nothing in the spec for GET blocks using message bodies with it. Elastic search famously uses(used?) bodies with GET requests.
unless you control every hop between client and server, GET bodies can be arbitrarily dropped, and can't be relied upon
Re: Defining a new HTTP method: HTTP Search (2021)
#110Earlier quoted context omitted.
Yes, that’s also lost when you do POST. Which is by design though. A HTTP Search seems like only drawbacks.
SEARCH can have a request body. Many systems limit the length of the URL, so this is significant.
If I send a request body with GET, what modern systems would even have a problem with that? Is there some caching middleware somewhere that I've never heard of or just ignored that will screw it up?
If there was a GET-with-body http verb I'd probably use it at one point or another, but I often wonder where plain GET would start blowing up if I just used it for that.
Honestly, I think rest is a mess, and that everything should just be POST with no values in the url at all.