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

81–90 of 131 posts

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

#81

Post by 411111111111111 »

hakanito wrote: post #73
adql wrote: post #71

Earlier quoted context omitted.

So can POST. It's entirely redundant

From reading the article, one of the key items addressed by HTTP Search is caching. POST requests are usually not safe to cache

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

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

#83

Post by kevincox »

nonethewiser wrote: post #64

Alternative naive solution: Add a body to GET requests. As I said, this is totally naive. Is there some obvious reason why this is a terrible idea, or not really possible?

Because a lot of existing proxies and other middleware will just drop the body. Or even worse not consider it in caching decisions but still proxy it.

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

#84

Post by afiori »

yashap wrote: post #49

I’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 sear…

I would say that people should be more open to using HTTP in non-REST ways.

Sometimes you want to send a request and receive a response, with arbirtrary restrictions and side effects that suit your cases.

There are a lot of good reason for rest to exists, but also sometime you want to POST /open-garage-door?t=5-minutes and call it a day

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

#85

Post by forgotmypw17 »

paulddraper wrote: post #66
hartator wrote: post #22

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

The limit of a GET request's length is at least several K on most systems I've used, so it's rarely an issue.

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

#86

Post by tacone »

brabel wrote: post #72
tacone wrote: post #69

Earlier quoted context omitted.

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

I'm sorry, but isn't that the most basic thing possible about GET and POST?? GET is used to read a resource, POST to write to it... why would you NOT expect writing to a resource to invalidate caches of that resource??

Because usually GET /posts gets you a list of posts, POST /posts create a new one.

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

#87

Post by JulianWasTaken »

tacone wrote: post #86
brabel wrote: post #72

Earlier quoted context omitted.

I'm sorry, but isn't that the most basic thing possible about GET and POST?? GET is used to read a resource, POST to write to it... why would you NOT expect writing to a resource to invalidate caches of that resource??

Because usually GET /posts gets you a list of posts, POST /posts create a new one.

I don't know what level of incredulity is appropriate in my opinion (probably not as much as the parent comment), but isn't that another good reason to expect cache invalidation? Surely creating new posts would expectedly invalidate the list of posts cached, it has to now include at least one new one.

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

#88

Post by paulddraper »

forgotmypw17 wrote: post #85
paulddraper wrote: post #66

Earlier quoted context omitted.

SEARCH can have a request body. Many systems limit the length of the URL, so this is significant.

The limit of a GET request's length is at least several K on most systems I've used, so it's rarely an issue.

That's not as much as you might think.

There's a reason elasticsearch accepts POST

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

#89

Post by bastawhiz »

cratermoon wrote: post #62
bastawhiz wrote: post #17

Earlier quoted context omitted.

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.

Nothing about GQL in particular is necessary to appreciate the need for this. Consider the Stripe API, where you might fetch invoices and expand the customers for each of those invoices, and then fetch the default payment methods for each of those customers. Stripe does this with a mess of query string parameters over a REST-ish API, but it could be accomplished much better with a request body.

GQL solves this problem in a particular way, but even folks who don't turn to GQL still have this problem.

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

#90

Post by dragonwriter »

adql wrote: post #71
paulddraper wrote: post #66

Earlier quoted context omitted.

SEARCH can have a request body. Many systems limit the length of the URL, so this is significant.

So can POST. It's entirely redundant

Verbs 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.
Post reply on HN