[Update: fifth and final question added] I’ve been thinking a bit about REST recently while working on a new data-oriented application. REST in its now-broadened meaning is easy to explain: pieces of data (likely XML-encoded) sit out there on the web, and you manipulate them using HTTP‘s GET, PUT, and DELETE methods (practically CRUD, except that the Create and Update parts are combined into PUT). Try explaining SOAP, much less the essence of the whole WS-* family in one easy sentence like that, and you’ll see the difference.
This very simplicity should raise some alarm bells, though. RDF also has an apparently simple data model, but for RDF 1.0, at least, the model turned out to be painfully incomplete, as I found out when I implemented my RDF parsing library. Is REST hiding any of the same traps? RESTafarians point out that REST is the basis of the Web’s success, but that’s really only the GET part (and its cousin, POST). Despite WebDAV, we have very little experience using PUT and DELETE even for regular web pages, much less to maintain a data repository. Even the much-touted RESTful web services from Amazon and eBay are GET-only (and POST, in eBay’s case); in fact, many, if not most firewalls come preconfigured to block PUT and DELETE, since web admins see them mainly as security holes.
My gut feeling is that REST is, in fact, more manageable than XML-RPC or WS-* for XML on the Web, but that we have a lot of issues we’ll need to work out first. Data management is never really simple, and while WS-* makes it harder than it has to be, even the simplest REST model cannot make it trivial. I’m going to post some of my own questions about REST design from time to time in this weblog, as I think of them, and I’ll look forward to hearing from people who have already dealt with or at least thought about these problems on their own.
Here are my questions so far:
Pingback: Quoderat » REST design question #1: identification
Pingback: Quoderat » REST design question #2: listing and discovering resources
Pingback: Quoderat » REST design question #3: meaning of a link
Pingback: Quoderat » REST design question #4: how much normalization?
Pingback: Quoderat » REST design question #5: the “C” word (content)
Pingback: AsynchronousBlog
Pingback: Raw
Pingback: Lost Boy
Pingback: 42
Next question: how to succesfully maintain a session with user authentication?