WE are designing an iPhone app that will call back to a RESTful service running in Tomcat. We need to send many query parameters and have exceeded the maximum that the phone will allow.
Would it be RESTful to use a PUT call with the parameters in the body, even though the intent in not to modify the server? A POST does not seem correct because it is not idempotent, while a PUT is (and thus more closely resembles the behavior or of a GET).
Thanks.
You have three options that are maximally conformant with HTTP:
First, you have the option of sending your params compressed in some fashion to form a shorter URL.
Second, there's nothing about GET that says you can't send a message-body in the request, in whatever Content-Type or -Length you choose. Not all servers support this, but the HTTP protocol itself does.
Third, you can POST the parameters to a /queries/ resource, and have that respond with 201 Created and a new URL (like /queries/78a65g82) in the Location response header, which the client then calls GET on (repeatedly, or even in Ranges, if that's a benefit) to retrieve the result.
If you want it RESTful, you could go about it this way: PUT the parameters to the server (at a location of your choosing), or you could POST them and let the server place them for you. Either way, you have just created a resource that holds the parameters you need. Then you send a GET referring to that particular resource. In answering your GET, the server therefore knows where to get its large set of parameters. That would be RESTful.
That said, however, sending two requests isn't very efficient, if you can do the same thing with a single request. I'd just try to be pragmatic.
Consider this: PUT tells proxies that they shouldn't cache the response, but a retry (by any infrastructure element along the line) is definitely possible, since it's idempotent (just like GET). What does GET give you over PUT? The response can be cached. But with that large number of parameters, I would assume that most requests will be unique anyway, right? So, caching isn't going to deliver much pay off very often. Therefore, using PUT seems to be the pragmatic, and thus the correct choice.