Generally speaking, the REST community seems to dislike complex data in GET requests. I wonder if there is a good principle behind this, or is it just reifying the (arbitrary url length) restrictions on GET dictionaries?
I am happy with the correspondence between urls and resources, but why can't my GET requests take complex data in the body of the request, in json or xml (which is allowed by the HTTP spec)?
The point of GET as I understood it was that GET requests signal that they don't modify server state. This seems orthogonal to the complexity of the request. Yet many people suggest that complex queries be created with a PUT or POST, and then referred to in a GET.
This seems to be elevating an convention (of not having bodies on GET requests) to the status of a principle, with unfortunate side effects: having to maintain the state of another object that doesn't deserve to be a resource on its own -- that is the query.
But perhaps there is some other principle I am missing -- I welcome your comments!
The fear is that existing web intermediaries will drop your GET body. Fortunately the new httpbis specs have reworded the text on get bodies and made it a little less scary. Personally, I'm considering using gets with bodies myself because I want to log unsafe requests and at the moment I have no easy way to identify if a POST is safe or not. If you have control over the components that sit between your user-agent and origin server then I say go ahead, use GETs with bodies.
来源：https://stackoverflow.com/questions/9010724/rest-and-get-again