9 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.
- 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.
- 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.
- 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.
- crazygringo 3y agoYes, but it can't be used as a hyperlink or typed into the browser bar. HTTP is a two-way messaging protocol. What's being talked about here is the capabilities in hyperlinks. Totally different.
- slondr 3y agoThat sounds like a deficiency of browsers, not of URLs. Browsers can already make arbitrary HTTP requests, and there are some rudimentary ways to expose this in hypertext (such as forms or XHR), but there’s nothing stopping a browser from letting you dump a full HTTP request into a text field and sending it.
- 9dev 3y agoYou're ignoring such a huge part of the HTTP specification there, like request idempotency, caching, the security model, and surely stuff I'm forgetting right now. HTTP, at its heart, is a way to compose an action from a verb and a noun - such as "get this", or "update that". The request method, or verb, is intertwined with the URI, or resource, the noun - together, they form the action the user agent intends to carry out. "GET /foo" is entirely distinct from "POST /foo", and there are lots of considerations why it has been implemented like that. I cannot recommend reading the spec (or letting ChatGPT summarise it for you) enough, it will really make more sense. Having said all that, I know what situations you are referring to - say, issuing a PATCH request with an HTML form, or circumventing some redirect bug with a POST request. Still, all of those problems hint at some other, more general issue, and solving such inconvenience would come at the price of a completely broken HTTP specification. Protocols like email, or HTTP, have only been around for so long because they were designed elegantly and carefully. Let's not break that for convenience' sake :)
- sceutre 3y agoSounds like what curl does. Maybe curl:{curl commandline}
- GloomyBoots 3y agoThis is an interesting idea for a browser extension. Maybe needs a change in name from URL/URI. Could be a DURI, Discrete Universal Record Interaction. Just spitballing. You could share one-liners similar to how one might share curl command-lines but expect them to work in multiple environments.
- 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.
- 3y ago
- 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.
- 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.
- 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
- 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.
- 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