tags:

views:

71

answers:

3

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.

A: 

It violates the spirit of REST, but if it works, be pragmatic.

Snekse
Is there a RESTful way to do it? I'm not a stickler for the letter of the law (or specification in this case), but would like to follow the standards if there is a way.
Ralph
+3  A: 

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.

fumanchu
I think you may find some proxies will not forward a the body of a GET request.
Darrel Miller
Like Darrel set, you shouldn't pass GET message-payloads, it could work in your dev-setup, but can crash in your prod-setup. It is just too unreliable and the routing (and the involved proxies) often not under you control.
manuel aldana
+1 for the /queries/78a65g82 suggestion, this is what we use.
balupton
+1  A: 

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.

jbrendel
@jbrendel: As I said in an earlier comment, the reason we have many parameters is that each one is the ID of a record already on the iPhone. We are trying to keep from resending those records on a refresh. Your comment about not caching and uniqueness is apropos.
Ralph