On 7/20/2011 1:04 PM, Joe Hourcle wrote:
> On Jul 19, 2011, at 11:33 AM, Ralph LeVan wrote:
>
>> Where at all possible, I want a true REST interface.  I recognize that
>> sometimes you need to use POST to send data, but I've found it very helpful
>> to be able to craft URLs that can be shared that contain a complete request.
> But there's more than just the URL that's used in REST.  As it uses
> HTTP, you could vary the response based on the Accept-Language or
> Accept headers.

While that is pure REST, I find it very difficult to debug, and also 
very difficult to then have a unified architecture for browsers as well 
as non-browser software clients -- since you cant' really control what 
accept headers a browser sends (and sometimes you DO want a non-HTML 
response to a browser -- download in EndNote format for instance), and 
most browsers can't send PUT/DELETE either.

The best compromise seems to having equivalents for everything that can 
be expressed in a GET/POST with standard headers.

For instance, the Rails framework will respect Accept headers for 
content-negotiation if sent, but you can ALSO use elements in the URL  
path instead:

GET /foo
     with Accept header application/xml
is equivalent to:
GET /foo.xml

And likewise, the Rails framework provides "magic query" params that let 
you express PUT/DELETE as a POST. (This isn't perfect, because 
PUT/DELETE _are_ supposed to be idempotent, whereas POST is not 
neccesarily. But PUT/DELETE are _not_ 'safe', and GET is 'safe', so it's 
not safe to use GET to represent a PUT/DELETE).

PUT /foo
   is equivalent to
POST /foo
       with key/value _method=PUT included in form-encoded body

But even that kind of assumes that the body will be form-encoded, 
whereas with 'pure REST' it's often convenient to have it be something 
else (like XML), but then there's no clear way to send that _method=PUT.

It gets complicated. But I think trying for pure REST just for the sake 
of purity ends up making things more complicated, including making your 
application code much more complicated, which serves nobody. Even this 
kind of modified "pure REST but with simulation through GET/POST without 
relying on request headers", like Rails does, kind of requires a 
framework like Rails to do it for you to keep from getting out of hand.

I think we just do the best we can, keep in mind the principles/goals of 
REST, rather than any particular picky rules, try to get as close to 
them as you can without having to make your application code become 
monstrous (and hard to understand for the developer/debugger).

Jonathan