7 ms·
One 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 t
by asattarmd 3y ago
One 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 https://google.com/search<some-special-character><query> https://google.com/search<some-special-character><query> where query can be arbitrarily large (>2000 URL length restriction) and the browser is smart enough to treat only https://google.com/search https://google.com/search as the URL and anything after that as the body. The complete "URL" can be big and shared anywhere else.
- hartator 3y agoYes, that’s also lost when you do POST. Which is by design though. A HTTP Search seems like only drawbacks.
- paulddraper 3y agoSEARCH can have a request body. Many systems limit the length of the URL, so this is significant.
- adql 3y agoSo can POST. It's entirely redundant
- hakanito 3y agoFrom reading the article, one of the key items addressed by HTTP Search is caching. POST requests are usually not safe to cache
- 411111111111111 3y agoIs search safe to cache though? It would definitely heavily depend on the dataset you're querying... Very little value in cached search results if you're searching through time-sensitive data such as logs or other live-datasets. Most datasets I've searched also has a concept of permissions, so person a couldn't be served the same cached result as person b... I think search can't be cached at the http level either, its too heavily dependent on the data you're searching through so you'd have to implement it in the application anyway. the article does make a good point though: a `get` request that supports a `body` would be nice, and thats pretty much all they're arguing for with the `search` verb.
- lokar 3y agoThe normal cache controls apply, so you can make it as safe as you need.
- dragonwriter 3y agoVerbs specify safety/idempotency guarantees for API-blind middleware, as well as whether (if either applies) a body needs taken into account; POST is not idempotent, SEARCH/QUERY is safe, and therefore also idempotent, but differs from GET in that that guarantee is body-specific.
- adql 3y agoMight as well just say "ok now GET can have body" instead of all that noise
- dragonwriter 3y agoWon’t retroactively change things that support GET to support GET-with-body. A new verb makes it much more likely that anything that supports the verb supports the desired semantics. (Of course, you could instead bump the HTTP version for support of GET-with-body, but given how HTTP/2 and HTTP/3 are defined in terms of HTTP/1.1, you’d need three new versions of HTTP for a change to core verb semantics. A new verb, again, is far simpler.)
- forgotmypw17 3y agoThe limit of a GET request's length is at least several K on most systems I've used, so it's rarely an issue.
- paulddraper 3y agoThat's not as much as you might think. There's a reason elasticsearch accepts POST
- forgotmypw17 3y agoBut what exactly is the difference between POST and SEARCH? Both include the request parameters in the body, so they would be obscured from the user. Unless they aren't, in which case it is a matter of the choices made in the implementation. Is it implied idempotency and the lack of a confirmation dialog when the user reloads the page?
- jimktrains2 3y agoCachability, perhaps. You cannot cache a post, but may be able to cache a search or query verb.
- NoMoreNicksLeft 3y agoIf 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.
- fiddlerwoaroof 3y agoGET with a body is pretty useless because the standard doesn’t allow the body to affect the results. So, proxies, browsers, etc. are free to ignore the body when caching results.
- SpaghettiCthulu 3y agoeven though most servers support it AFAIK, many clients don't. Many will even silently discard the body when sending a GET request.
- 2h 3y ago> One advantage of GET is I can just copy the URL and share it. no, you cant. if the server requires any headers such as Authorization or Cookie, this method will fail.
- johngalt_ 3y agoThey are obviously talking about public urls.
- foolfoolz 3y agoit’s extremely to share urls needing auth with people who have the same access levels as you, such as in your company
- ivan_gammel 3y agoTypical scenario is to redirect to login and after successful authentication return back to the requested URL, so the method doesn’t fail if server is implemented correctly.
- hombre_fatal 3y agoIt’s not a “no you can’t” just because you know of some exceptions. And even then, they are still correct while you are not. You can copy the GET url even if it ultimately it requires authentication in a way that you can’t do it all for a POST request.
- candiddevmike 3y agoRelated, I wish there was a more standard way to include things like verb and headers in a URI. I hacked an implementation that parses /something#a:b&c:d to set the headers a and c, I was thinking for verb I could do https+get.
- sceutre 3y agoSounds like what curl does. Maybe curl:{curl commandline}
- dragonwriter 3y agoverbs don't identify a resource, so why would they be in a URI? A separate format to serialize a request spec is a good idea, sure, but it is a distinctly different thing than the URI of the resource referenced by the request.
- nerdponx 3y agoIs that not just the HTTP 1.1 format? It's a perfectly readable plain text format.
- crazygringo 3y agoI'm pretty sure you know what the parent means. Forget about what acronyms stand for. The thing that hyperlinks point to and you can type in your browser bar is called the URL or the link. And the point is that being able to specify a verb and headers in a link would be super useful in certain situations. Continue to call it a URL or URI and just change the "R" in those from Resource to Request, semantics problem solved. Or invent a new URA where "A" stands for "action" and it's a valid hyperlink. The naming of it is the least important part here.
- slondr 3y agoWe already have a format to identify an entire request including verb and headers. It’s called HTTP.
- graypegg 3y agoGuess that needs to be different than the ? query params. I wonder if you could use ?key=value as your signal for GET, and ?value as your signal for SEARCH. I think it's up to the service to parse the string that comes after ? in a URI so maybe that's a way to go.
- justinator 3y agoThat would unfortunately break the internet as a GET query without ?key=value and just ?value is perfectly reasonable.
- phailhaus 3y agoThe primary use case of SEARCH is programmatic, e.g., making complex requests to a search API in order to render results. Those are API requests, they're not being shared around.
- BugsJustFindMe 3y ago> 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.
- preseinger 3y agounless you control every hop between client and server, GET bodies can be arbitrarily dropped, and can't be relied upon
- deepzn 3y agoThe proposal has changed the name to QUERY, just yesterday.
- imnotjames 3y agoThis is why the RFC suggests you redirect to a GET like /resource/queryABCD