Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defining a new HTTP method: HTTP Search (2021)

httptoolkit.com

Post reply on HN
Print view View original

61–70 of 131 posts

Re: Defining a new HTTP method: HTTP Search (2021)

#61

Post by sceutre »

candiddevmike wrote: post #26
asattarmd wrote: post #21

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 " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…

Related, 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.

Sounds like what curl does. Maybe curl:{curl commandline}

Re: Defining a new HTTP method: HTTP Search (2021)

#62

Post by cratermoon »

bastawhiz wrote: post #17
cratermoon wrote: post #13

I'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…

A great example of this today is GraphQL. Even if you disagree with the premise of GQL, you can understand how you can have complicated filtering and sorting logic, and conditional expansion of nested resources. For a nontrivial data model, you may want to select only a minimal number of fields on each nested resource. Having lots of different variants of the same endpoint to serve the same query with different shape…

I knew someone would bring up GraphQL, as I consider it a sort of way to present a database schema in JSON, so of course it would result in complex SQL-like queries. I understand why it works for Facebook, but it's not something I've ever reached for to solve any programming problem I've had.

Re: Defining a new HTTP method: HTTP Search (2021)

#63

Post by politician »

I used a SEARCH verb for an REST API years ago. Granted, we only had to support clients that we wrote ourselves. Semantically, however, it made a lot of sense to include a payload in the request body describing the query.

No one else needed to know or care that it existed.

Re: Defining a new HTTP method: HTTP Search (2021)

#65

Post by GloomyBoots »

candiddevmike wrote: post #26
asattarmd wrote: post #21

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 " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…

Related, 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.

This 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.

Re: Defining a new HTTP method: HTTP Search (2021)

#66

Post by paulddraper »

hartator wrote: post #22
asattarmd wrote: post #21

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 " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…

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.

Re: Defining a new HTTP method: HTTP Search (2021)

#67

Post by phailhaus »

asattarmd wrote: post #21

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 " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…

The 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.

Re: Defining a new HTTP method: HTTP Search (2021)

#68

Post by cratermoon »

slondr wrote: post #50
cratermoon wrote: post #13

I'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.

That reminds me of reporting software like Crystal Reports. A thin veneer over a relation model (or, often, a collection models abstracted). I understand why businesses choose them, but they've always struck me as a bit of a shortcut. I'm always more curious about what the business does with the reports, and why we can't program to those requirements.

Re: Defining a new HTTP method: HTTP Search (2021)

#69

Post by tacone »

zeroimpl wrote: post #47

TIL 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.

Incredible, I did not know that. Does anybody point out to some resources to learn more about this behavior?

Re: Defining a new HTTP method: HTTP Search (2021)

#70

Post by samwillis »

If they do add this I hope they also add support to the Browser History pushState API to set the request body. You can obviously set an arbitrary JS state object, but for server rendered "html over the wire" single page apps it would be nice to be able to do a pushState that is sent to the server on refresh.
Post reply on HN