HTTP GET with request body

 

I'm developing a new RESTful webservice for our application.

When doing a GET on certain entities, clients can request the contents of the entity. If they want to add some parameters (for example sorting a list) they can add these parameters in the query string.

Alternatively I want people to be able to specify these parameters in the request body. HTTP/1.1 does not seem to explicitly forbid this. This will allow them to specify more information, might make it easier to specify complex xml requests.

My questions:

  • Is this a good idea altogether?
  • Will HTTP clients have issues with using request bodies within a GET request?

    • http://tools.ietf.org/html/rfc2616

    Roy Fielding's comment about including a body with a GET request.

    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

    Yes, you can send a request body with GET but it should not have any meaning. If you give it meaning by parsing it on the server and changing your response based on its contents, then you are ignoring this recommendation in the HTTP/1.1 spec, section 4.3:

    [...] if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

    And the description of the GET method in the HTTP/1.1 spec, section 9.3:

    The GET method means retrieve whatever information ([...]) is identified by the Request-URI.

    which states that the request-body is not part of the identification of the resource in a GET request, only the request URI.

    While you can do that, insofar as it isn't explicitly precluded by the HTTP specification, I would suggest avoiding it simply because people don't expect things to work that way. There are many phases in an HTTP request chain and while they "mostly" conform to the HTTP spec, the only thing you're assured is that they will behave as traditionally used by web browsers. (I'm thinking of things like transparent proxies, accelerators, A/V toolkits, etc.)

    This is the spirit behind the Robustness Principle roughly "be liberal in what you accept, and conservative in what you send", you don't want to push the boundaries of a specification without good reason.

    However, if you have a good reason, go for it.

    You will likely encounter problems if you ever try to take advantage of caching. Proxies are not going to look in the GET body to see if the parameters have an impact on the response.

    链接地址: http://www.djcxy.com/p/1932.html

    上一篇: SOAP vs REST（差异）

    下一篇: 带请求正文的HTTP GET