[For Arnon Rotem-Gal-Oz’s Article: http://dobbscodetalk.com/index.php?option=com_myblog&show=CRUD-is-bad-for-REST.html&Itemid=29 ]In one of my previous posts (Rest: good, bad and ugly), I made a passing comment, about how I think using CRUD in RESTful service is a bad practice. I received a few comments / questions asking why do I say that – so what’s wrong with CRUD and REST?
On the surface, it seems like a very good fit (both technically and architecturally), however scratch that surface, and you’d see that it isn’t a good fit for either.
REST over HTTP is the most common (almost only) implementation of the REST architectural style - to the point REST over HTTP is synonymous with REST. I would say most of the people who think of REST in CRUD terms, think about mapping of the HTTP verbs.
CRUD which stands for Create, Read, Update and Delete, are the four basic database operations. Some of the HTTP verbs, namely POST, GET, PUT and DELETE (there are others like OPTIONS or HEAD) seem to have a 1-1 mapping to CRUD. As I said earlier they don’t. The table below briefly contrast HTTP verbs and CRUD
| Verb | CRUDdy Candidate | Actually |
| GET | SELECT (Read) | Get a representation of a resource. While it is very similar to SELECT it also has a few features beyond an out-of-the-box SELECT e.g. by using If-Modified-Since (and similar modifiers) you might get an empty reply. |
| Delete | Delete | Maps well |
| PUT | Update |
Put looks like an update but it isn’t since:
1. You have to provide a complete replacement for the resource (again similar to update but not quite) 2. You can use PUT to create a resource (when the URI is set by the client) |
| POST | Insert | It can be used to create a but it should be a child/subordinate one. Furthermore, it can be used to provide partial update to a resource (i.e. not resulting in a new URI) |
| OPTIONS | ? | Get the available ways to continue considering the current state or the resource |
| HEAD | ? | Get the headers or metadata about the resource (which you would otherwise GET) |
The way I see it, the HTTP verbs are more document oriented than database oriented (which is why document databases like CouchDB are seamlessly RESTful). In any event, what I tried to show here is that while you can update, delete and create new resources the way you do that is not exactly CRUD in the database sense of the word – at least when it comes to using the HTTP verbs.
However, the main reason CRUD is wrong for REST is an architectural one. One of the base characteristics(*) of REST is using hypermedia to externalize the statemachine of the protocol (a.k.a. HATEOS– Hypertext as the engine of state). The URI to URI transition is what makes the protocol tick (the transaction implementation by Alexandros discussed in the previous post shows a good example of following this principle).
Tim Ewald explains this nicely (in a post from 2007…) :
… Here's what I came to understand. Every communication protocol has a state machine. For some protocols they are very simple, for others they are more complex. When you implement a protocol via RPC, you build methods that modify the state of the communication. That state is maintained as a black box at the endpoint. Because the protocol state is hidden, it is easy to get things wrong. For instance, you might call Process before calling Init. People have been looking for ways to avoid these problems by annotating interface type information for a long time, but I'm not aware of any mainstream solutions. The fact that the state of the protocol is encapsulated behind method invocations that modify that state in non-obvious ways also makes versioning interesting.
The essence of REST is to make the states of the protocol explicit and addressableg by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you're moving to, making that your new state. A state's representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app's protocol can't work that way too. (The ATOM Publishing protocol is the canonical example, though its easy to think that its about entities, not a state machine.)
If you are busy with inserting and updating (CRUDing) resources you are not, in fact, thinking about protocols or externalizing a State machine and, in my opinion, miss the whole point about REST.
CRUD services leads and promoted to the database as a service kind of thinking (e.g. ADO.NET data services) which as I explained in another post last year is a bad idea since:
-
It circumvents the whole idea about "Services" - there's no business logic.
-
It is exposing internal database structure or data rather than a thought-out contract.
-
It encourages bypassing real services and going straight to their data.
-
It creates a blob service (the data source).
-
It encourages minuscule demi-serices (the multiple "interfaces" of said blob) that disregard few of the fallacies of distributed computing.
-
It is just client-server in sheep's clothing.
The main theme of this and the previous post is that if we try to drag REST to the same old, same old stuff we always did we wouldn’t really get that many benefits. In fact, the “old” ways of doing that stuff are probably more suitable for the job anyway since they have been in use for a while now. and they are “tried and tested” (“You can’t win an argument with an idiot, he’ll just drag you down to his level and beat you with experience” …). REST is just a different paradigm that RPC, ACID transactions and CRUD.
* I know I sound like a broken record on that but our industry has a history diluting terms to a point they almost stop being useful (SOA comes to mind..). The way I see it you can have 3 levels on your way to REST over HTTP:
-
You can be using HTTP and XML/JSON – this is level 1 or “Using standards”.
-
You can be using the HTTP verbs properly and/or applying document oriented communications – this is level 2 or “Rest-like” interface
-
You can conform to all REST constraints and be at level 3 or “RESTful”.
All levels can be useful and bring you merit but only the 3rd is REST
