The more i read about REST, the more convinced i am that nobody really understands it.
i'll lump myself into that heap, mind you, so feel free to lord your interpretation of REST over me.
Ultimately, REST seems to be based on a few fairly straight-forward concepts:
1) A simple URL that contains the context of a given action (e.g. http://example.com/groups/elements/item)
2) A CRUD (Create/Read/Update/Delete) action that maps to one of several existing HTTP commands (e.g. POST/GET/uhm…POST/DELETE)
3) (and this is where things get goofy) a payload of a command to define the set of actions to take on the object defined in 1.
4) A response object.
#3 and #4 are generally where things get funky. Reading the highly popular Dare Obasanjo post, i see that he uses OMPL and XML as the payload delivery methods, mostly because they're XML based, well defined, and structured. The retuned result is in OMPL much for the same reasons.
i get good Mr. Obasanjo's remarks toward not overloading the URI with commands, but i just can't help think that what he's using for the incoming payload effectively flies in the face of the rules of the UNIX.
See, i don't know any browsers that deliver form content as XML. They all use MIME encoding (e.g.
they send things like "&bar=gorp" instead of:<foo><bar>gorp</bar></foo>
There are libraries out there that encapsulate and abstract that sort of thing away from you, but it means that you can't really just crack open a browser and play with an interface. i know that in his conclusion he states:
From the end user or application developer's perspective the above actions aren't fundamentally different. In both cases, the user is removing part of their subscription list which in turn deletes some subset of the <outline> elements in the user's subscriptions OPML file.
But they are fundementally different. Granted, the URLs aren't simple, but with minimal effort, i could toss a few links onto an HTML page and be able to control NewsGator. Using Dare's constructs, i can't. Yes, his are more "elegant" and "clean", but they're not simple.
When i say "the rules of UNIX" i mean a few things:
1) Have small things that do one task, but can be fitted together
2) Be open about what you can accept, but strict about what you output.
That's really about it. i can easily see where it makes sense to create services that accept XML, JSON and MIME encoded data, and output the same. Yeah, that makes life harder for service providers, but then, it should be. i know for certain that i have a machine that i can reliably run code on. i have no idea if my service consumers have that ability. By providing the lowest barrier of entry, i make my API more appealing and more likely to be used. Heck, that philosophy is what drove Pipes and YUI and they're not really hurting for adoption.
It just seems like i must be missing something here if every article i read never talks about that.
Save This Page
