Can anyone steelman this idea for me? Seems like an incredible waste of time to make this.
Defining a new HTTP method: HTTP Search (2021)
41–50 of 131 posts
Re: Defining a new HTTP method: HTTP Search (2021)
#42I want this. SEARCH/POST APIs forever.
Re: Defining a new HTTP method: HTTP Search (2021)
#43One 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. no, you cant. if the server requires any headers such as Authorization or Cookie, this method will fail.
It’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.
Re: Defining a new HTTP method: HTTP Search (2021)
#44What I like about this proposal is that no one has to use it. There's lots of comments here saying why they prefer GET, and those people are welcome to keep using it- GET will remain unchanged.
But for those applications where having a complex body in the query request is a better choice, this tool can be available. I think that's a win.
Re: Defining a new HTTP method: HTTP Search (2021)
#45Earlier quoted context omitted.
verbs 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.
I'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 sol…
We already have a format to identify an entire request including verb and headers. It’s called HTTP.
Re: Defining a new HTTP method: HTTP Search (2021)
#46One 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…
Guess 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.
That would unfortunately break the internet as a GET query without ?key=value and just ?value is perfectly reasonable.
Re: Defining a new HTTP method: HTTP Search (2021)
#47TIL sending a POST request to a URL invalidates the cache for GET requests of the same URL.
Going to have to review my REST APIs to make sure that’s not a problem.
Re: Defining a new HTTP method: HTTP Search (2021)
#48Or just use GET since it already works. I don't see any problems with large query params. You can also split the search into a POST request and a GET request for the result.
I’m pretty sure most browsers have fairly low limits for uri length.
Re: Defining a new HTTP method: HTTP Search (2021)
#49I’d like to see this (or something like it) ship. Right now the two most common alternatives are:
1) GET, but base64 encode a json payload as a query param. Main downsides are that you can hit URL size limits, it makes the client and server slightly more complex (base64 encode/decode), and it sucks with browser dev tools - can’t nicely inspect the request in the browser, have to copy and decode it
2) Use POST to search. This confuses both machines and people. On the machines side, it doesn’t play well with caches, retry middleware, etc. On the people side, it confuses developers, ppl monitoring metrics, etc. - you think it’s creating something but it isn’t. Basically goes against all the reasons we have separate GET/POST/PUT/PATCH/DELETE methods in the first place
Yeah, we have workarounds, but they have pretty significant downsides. I’d rather have this new method. Honestly, I think one of the main reasons ppl reach for RPC frameworks over RESTful APIs is the awkwardness around making search queries - this would really fix that issue.
Re: Defining a new HTTP method: HTTP Search (2021)
#50I'm trying to imagine an example of the authors primary use case: "a complicated data retrieval, sending lots of data but not changing the server state". Is he imagine sending something like a SQL statement SELECT with multiple WHERE and JOIN clauses using a recursive CTE? If defining the attributes of the thing to return takes that much complexity, maybe that's a sign the endpoint is poorly designed, rather than GET…
We actually run into the query limit problem super often where I work. User-facing search pages for very complicated data models create very complicated URLs quickly.