 |
 |
Actually, what I really wanted to know was whether or not the people here-subscribed would expect a proper REST interface to have an associated media type and to use hypertext as the engine of application state. In the link I originally provided [1], that's the final distinguishing characteristic of a REST interface. The discussion here seems to be about RPC-URI tunneling or HTTP-based Type I. But that's useful as well, since it indicates I'm probably over concerned with architectural style, and should just build something. Thanks, Devon [1] http://www.nordsc.com/ext/classification_of_http_based_apis.html On Wed, Jul 20, 2011 at 2:35 PM, Jonathan Rochkind <[log in to unmask]> wrote: > 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 > -- Sent from my GMail account.