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
