91–100 of 131 posts
Earlier quoted context omitted.
Middle boxes can arbitrarily limit the request URL size in certain cases.
Sure, but in the times of encrypted traffic, the only middle boxes capable of limiting the query should be ones explicitly added by the service owner.
This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.
Could be used for e.g. SQL over HTTP
Right now, you have two main options:
Use a GET, and squeeze all the parameters you need in the URL or headers somewhere
Use a POST, and have the request considered as unsafe & uncacheable
Wanting a special method for search hurts the conceptual integrity of HTTP, where resource representation is the core idea to build on top, it isn’t supposed to be just a request/response protocol.
Right now, you have two main options: Use a GET, and squeeze all the parameters you need in the URL or headers somewhere Use a POST, and have the request considered as unsafe & uncacheable Third option: you POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached. Wanting a special method for search hurts the conceptual integrity of HTTP, whe…
It works very well, is completely transparent to the end user, has automatic query logging, and provides a clean URL that can be easily shared.
Earlier quoted context omitted.
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.
That being said, I don’t see this feature being particularly beneficial either. Only the caches which observed the request could know to purge the cache. So you can’t actually rely on it for cache invalidation.
Earlier quoted context omitted.
Funny you should say that: https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...
I understand the benefits of QUERY over GET because GET is expected to return a resource in the response. Why not just use POST though? Send a post message to a server asking to conduct a search and sending the results of that query in the response?
Not idempotent: POST
idempotent/not safe: PUT (body matters), DELETE (no body)
safe: QUERY (body matters)/GET (no body)
That’s why QUERY is needed. POST is not a good substitute.
Earlier quoted context omitted.
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, it…
Earlier quoted context omitted.
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
Is it implied idempotency and the lack of a confirmation dialog when the user reloads the page?
This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.