60

I don't want to see so long parameters string in the URI. So, can GET method use json data?

In my situation, I need to filter the result given kind of parameters. If there are a lot of parameter, the length may exceed the limit of URI. So, is there best practice for this problem?

HappyLiang
  • 632
  • 1
  • 5
  • 9
  • 3
    This question is asked on SO at least once a week. Always the same two oppions are proposed as answer: 1) yes, `GET` with a request body is RESTful, 2) no, it is not. We all don't learn anything new from writing down our oppinions again and again. For now I vote to close this question because it is a duplicate. It should also be closed because answers are primarily opinion based. –  Apr 11 '15 at 18:34

2 Answers2

69

In theory, there's nothing preventing you from sending a request body in a GET request. The HTTP protocol allows it, but have no defined semantics, so it's up to you to document what exactly is going to happen when a client sends a GET payload. For instance, you have to define if parameters in a JSON body are equivalent to querystring parameters or something else entirely.

However, since there are no clearly defined semantics, you have no guarantee that implementations between your application and the client will respect it. A server or proxy might reject the whole request, or ignore the body, or anything else. The REST way to deal with broken implementations is to circumvent it in a way that's decoupled from your application, so I'd say you have two options that can be considered best practices.

The simple option is to use POST instead of GET as recommended by other answers. Since POST is not standardized by HTTP, you'll have to document how exactly that's supposed to work.

Another option, which I prefer, is to implement your application assuming the GET payload is never tampered with. Then, in case something has a broken implementation, you allow clients to override the HTTP method with the X-HTTP-Method-Override, which is a popular convention for clients to emulate HTTP methods with POST. So, if a client has a broken implementation, it can write the GET request as a POST, sending the X-HTTP-Method-Override: GET method, and you can have a middleware that's decoupled from your application implementation and rewrites the method accordingly. This is the best option if you're a purist.

Pedro Werneck
  • 38,032
  • 6
  • 53
  • 74
  • What do you think about http://stackoverflow.com/a/983458/1907906 ? –  Apr 11 '15 at 18:36
  • @Tichodroma Fielding is saying the exact same thing. A GET body has no parse semantics defined by the HTTP protocol, but that doesn't mean it can't be useful in a REST API using HTTP as the transport protocol. It only means it's irrelevant for the transport protocol itself and might not be respected by some implementation. – Pedro Werneck Apr 11 '15 at 20:10
10

To answer your question, yes you may pass JSON in the URI as part of a GET request (provided you URL-encode). However, considering your reason for doing this is due to the length of the URI, using JSON will be self-defeating (introducing more characters than required).

I suggest you send your parameters in body of a POST request, either in regular CGI style (param1=val1&param2=val2) or JSON (parsed by your API upon receipt)

jfrattarola
  • 123
  • 6
  • 2
    Such a request is RPC over HTTP. It is not RESTful. –  Apr 11 '15 at 09:04
  • 2
    @Tichodroma Sorry, but that's simply wrong. If he's directing the call to a resource identified by an URI, with a method defined by the HTTP protocol, with POST semantics defined by the target resource, it's not RPC. It might not be REST either, but it's not RPC. It would be RPC if the JSON payload contained the identifier -- instead of the URI -- and the method to use -- instead of relying on the HTTP method semantics. – Pedro Werneck Apr 11 '15 at 20:14