5 ms·
Finally, the spec is crystal clear that message bodies on GET requests are not illegal.
by __david__ 12y ago
Finally, the spec is crystal clear that message bodies on GET requests are not illegal.
- colanderman 12y agoPardon my ignorance but how are GET payloads useful? Does that not violate REST principles?
- colanderman 12y agoFrom the horse's mouth; they are not useful: https://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/9962 https://groups.yahoo.com/neo/groups/rest-discuss/conversatio...
- wtetzner 12y agoI'm not sure how. As long as a GET request doesn't change your resources, it should be fine. The reason I can think of for sending a payload in a GET is if the data you wanted to send in a query string is too large.
- treve 12y agoIt's still a bad idea. It has no defined semantics, meaning that servers, clients, proxies and anything else are free to ignore or drop it. It also defeats caching and any other reasons why you would want to use GET over some other http requests. I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing.
- xxs 12y agoMy thoughts exactly - GET with payload virtually means no caching.
- masklinn 12y agoIf you've got to use body payloads, requests are probably way too big and unique for the involvement of caches browser or intermediate caches to be a good idea.
- masklinn 12y ago> I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing. Not all systems support practically unlimited URI payloads[0]. In the past, this forced either contorsion (gzipping URI payload) or piping everything through POST. For instance, let's say you've built a music identification system, people can send in files and get information about the file's data. This is a purely readonly request, the backend just uses its information to identify the file and fetch whatever data and metadata on the file's content it has. But historically there was no choice but to route it via a semantically unsuitable POST. [0] Apache defaults to 8190 bytes, IIS to 16384, Safari and Firefox support >100k but MSIE is limited to 2048
- nileshtrivedi 12y agoAnother example: Searching for images similar to a specified one.
- masklinn 12y agoA great example, image search already being fairly common (and being useful to all sorts of purposes)
- gioele 12y ago> It also defeats caching and any other reasons why you would want to use GET over some other http requests. It does not break caching. Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response.
- thegregjones 12y agoDo any caches operate like that?
- RobAley 12y agoNot many I would think. For compatibility with existing caches, you could do something like add an extra parameter to the URL with a hash of the message body. In the case of e.g. an image or music file given elsewhere in this thread, the cache doesn't actually need the full contents of the image file (like the backend does), just something like a hash to match it to a previous request.
- dragonwriter 12y ago> Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response. Well, except that since the body isn't defined as having semantics that determine the response, an cache based on the HTTP protocol spec has no reason to do that.
- ajanuary 12y agoTalking from a practical standpoint, to try and have GET requests with large parameters you could put the data in the message body, and then a hash of the message in the URL to avoid caching issues.
- argonaut 12y agoIs there something wrong with violating a REST principle?
- icebraining 12y agoThere is if you don't want to lose advantages that following them bring. That said, I don't see how this would break any REST principles.
- dragonwriter 12y agoThere's something wrong with breaking the semantics of GET; all the revision does is clarify that the syntax of HTTP is method-independent so that message bodies aren't syntax errors, but GET bodies still have no semantic meaning and ascribing one to them is likely to mean you server is doing things that clients, caches, etc., won't correctly handle.
- saryant 12y agoElasticsearch: it accepts JSON bodies in GET requests to define the parameters of a search. These can get quite large so it's preferable to encoding everything in the query string. The operation is read-only, so an argument can be made that a GET makes more sense than a POST. That said, I POST my search params to Elasticsearch anyways.
- robryk 12y agoAren't message bodies on GET supposed not to impact the returned result at all?
- colanderman 12y agoYes: http://stackoverflow.com/a/983458 http://stackoverflow.com/a/983458
- Joeri 12y agoIs that really restful though? If you need that many parameters to specify which resource you mean, you lose pretty much all of the benefit of a restful architecture.
- acdha 12y agoGET vs. POST is a question of whether the request is intended to change state. Using JSON for a query is nice for preserving structure (e.g. nesting a Boolean expressions, not needing PHP-style array notation, etc.) but it doesn't change the idea that it's a GET request which can safely be repeated without affecting server state, may be cached for other clients, etc.
- Cakez0r 12y agoHaving the parameters of your GET request in the query string or the request body doesn't have any semantic difference. You're just fetching a resource given some parameters, which doesn't violate REST principles.
- dragonwriter 12y agoThey aren't. HTTP has a layered design, and the structure of requests is a lower level feature than the semantics of specific request type -- a request can always have a body, but that doesn't mean that there aren't request types (e.g., GET) for which the body is meaningless. > Does that not violate REST principles? Most attempts to impose semantics on GET bodies would violate REST principles as well as breaking HTTP (given that GET responses are cacheable and the body is treated as not relevant to the response.)
- lttlrck 12y agoIs it really so different to URI encoded parameters?
- grk 12y agoPhusion passenger throws 500 on get requests with body, I guess now they might change that.
- FooBarWidget 12y agoActually we've already changed that. It's slated for 4.0.45, due next week.