Limitations of the GET method in HTTP
blogs.dropbox.com
blogs.dropbox.com
GETs can have bodies--- its just that some people who write software forget this.
A simple solution is to put a hash or maybe even just a body content length in the query string or a header so the server can make sure the body made it to it. If the the body doesn't make it, then it can inform the client retry with another less ideal HTTP method.
Yes. In other words, any HTTP request message is allowed to contain a message body,
and thus must parse messages with that in mind. Server semantics for GET, however,
are restricted such that a body, if any, has no semantic meaning to the request.
The requirements on parsing are separate from the requirements on method
semantics.
So, yes, you can send a body with GET, and no, it is never useful to do so.
This is part of the layered design of HTTP/1.1 that will become clear again once
the spec is partitioned (work in progress).
....Roy
Edit: As I mentioned on another follow up, you may need to vary on your checksum header to play nice with proxy caches, etc. Or mark your responses as uncachable.
So for example: QUERY example.com/api/thing ('{"thing_id": 00335}'::json)
Although it's debatable whether it's a better solution (semantically a request body should not influence the result of an HTTP GET response), but saying that "GET requests don’t have a request body" is false.
From: https://github.com/elasticsearch/elasticsearch-definitive-gu... :
> A GET request with a body? The HTTP libraries of certain languages (notably Javascript) don’t allow GET requests to have a request body. In fact, some users are suprised that GET requests are ever allowed to have a body.
> The truth is that RFC 7231 — the RFC which deals with HTTP semantics and content — does not define what should happen to a GET request with a body! As a result, some HTTP servers allow it, and some — especially caching proxies — don’t.
> The authors of Elasticsearch prefer using GET for a search request because they feel that it describes the action — retrieving information — better than the POST verb. However, because GET with a request body is not universally supported, the search API also accepts POST requests:
There should be a GET-like method that takes a (significant) request body but is otherwise semantically like GET (e.g., safe) -- essentially, it would represent asking for a representation of the result of applying a pure function to the resource identified by the URI rather than asking for a representation of the resource itself.
But no such function currently exists in HTTP/1.1 or any general purpose extension (there are highly-specific things like the SEARCH method, but that's not general purpose the way the base HTTP/1.1 methods and, say, PATCH are.)
Something like that completely decoupled from WebDAV is basically what I'd like to see.
Note this part of the accepted answer:
> So, yes, you can send a body with GET, and no, it is never useful to do so.
Or, lets just use POST.
Incidentally, you are supposed to be allowed to redirect in response to GET requests, but if you use JWT auth then you can't even do this because the non-standard header forces a preflight request, and CORS requests with preflight aren't allowed to redirect at all.
I don't even understand how it's supposedly secure to pass back JSON with a URL for your promise to trigger a redirect, but it's insecure to pass your browser a 3XX response to do the same thing automatically.
There's a difference between violating common patterns and breaking the specified semantics of the standard.
> E.g. you are supposed to redirect after a POST request so that users can't double submit a form
That's a common practice, but not a requirement of the HTTP standard the way that GET methods not having semantically-significant request bodies is.
RFC5323 is still a thing, and the HTTP verb mechanism is still extensible. Use the SEARCH verb, submit your complex query in the method body. It's up to you to define the query structure appropriate for your use case, but MongoDB's query language is a good starting place.
REPORT (also from WebDAV) is somewhat closer to a general GET-with-body, but still has some WebDAV baggage.
As long as we're picking nits, it doesn't really matter if a GET request modifies server state so long as the state after N requests is the same as the state after 1 request (idempotence).
1) It is a "safe" method.
2) It is an idempotent method.
A safe method (GET/HEAD) should not modify server state.
"In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. "
Whereas PUT & DELETE are also idempotent but not "safe".
> Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
I guess my point is that idempotence is the aspect that matters to clients - you can have side-effects if you really want, so long as the request can be safely repeated.
Of course, it's not actually-invisible: their next request might be a little bit faster.
"Same effect from 0 or more actions" implies "Same effect from 1 or more actions".
The private key of the API user is hashed with the full URL of the service. The user id is sent in the header of the request. The server looks up the user id and gets their private key, it then uses that key to hash the URL, comparing it to the one passed.
There is no way for a scraper or bot to get the HMAC token.
For a public interface you don't necessarily have that. Though once you are dealing with a service that can be modified by unauthenticated users you have larger problems from malicious interactive users than from accidents by scrapers, so I'm probably arguing an irrelevant point...
What they are doing with their delta API does seem like a GET is the correct option, and according to the spec a GET with a really long URI should be allowed.
It's good to raise awareness of this so http client and server software stops assuming that the URI is something small (historically entered by a human, or at least copied and pasted around)
- Using GET with a request body:
Per RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, section 4.3.1 [1]: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."
Although you can argue whether or not you should be able to define the semantics of such a request body within the context of the resource, it quickly becomes moot in the face of reality: there's a good chance it won't work due to whatever client or intermediary is involved.
- Using non-HTTP verbs (i.e. REPORT, SEARCH):
Again, one can argue over their validity, but since most clients or intermediaries will not support them, there's little practical use. In this particular case, I'd recommend against them since most developers will not be familiar with them, making your API less user friendly.
- Using POST:
Per RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, section 4.3.3 [2]: "The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics."
In other words, do whatever you want – such as executing a search query contained within the request body. This is semantically valid, widely supported and common practice. The only downside would be that caching of POST requests is not widely supported, although still possible. The spec even suggests an alternative solution: "Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of RFC7234). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2)."
In other words, you can implement a caching mechanism for your query resource that exposes itself through a URL structure, available for GET requests.
These are HTTP extensions, and are as much HTTP verbs as PATCH. The big problem is that REPORT and SEARCH are WebDAV extensions to HTTP, and their specs have WebDAV related baggage, and its at least as much "bad REST" to redefine the semantics of methods with existing standards as to use POST to get around the technical/practical problems with GET.
Could you elaborate on what you consider to be "bad REST" with regards to using POST in this case? The RFC clearly leaves the definition of the semantics of POST up to the implementation of that particular resource.
The only argument I could come up with, is that POST is not guaranteed to be idempotent or safe, whereas a search query would be. But a lack of guarantee doesn't exclude use cases where it would be.
I'm not saying POST is bad REST, I am acknowledging the claim by some that it is and, without debating whether or not it is, saying that using REPORT or SEARCH, as currently defined, is at least as bad as using POST from a REST point-of-view.
(I actually think that, in terms of using HTTP in a RESTful way, POST is the least-bad choice in terms of existing verbs, though it is not an exceptionally good fit -- its basically a case where POST-works-for-anything-for-which-no-other-method-seems-appropriate logic applies.)
If you happen to run into buffer size problems with GET headers, a POST can be an inconvenient answer (no caching). Or you create a new verb and customize your proxy's buffer settings for that special thing. This will make the pain explicit in your infrastructure.
But generally, I assume a complex operation behind a large URI. So a POST would do fine if the costs of the request are somewhat transparent to the user. And if you cannot do HTTP caching, an application cache would be the next thing to look for.
> For forms that use HTTP POST, it may not be safe to retry so the browser asks the user for confirmation first.
this always makes me a bit mad. the user has absolutely no idea what the server is doing... and most users are baffled by this message and can't understand why they would want to do anything else other than resubmit the form, in the vast majority of cases.
if it really is potentially dangerous (it can be) browsers should apologise, not offer the user a gun to shoot his feet with.
The client can decide to use query string or body. Most ruby web servers handle this transparently, so the app doesn't know if the params came from the query string or from the body.
In one of the cases I ended up using POST as well. It was easy as that resource didn't already have a POST method (like in this case).