Geeks With Blogs
Path Notes of a Kodefu Master blog

Arnon Rotem-Gal-Oz wrote an article for Architect Zone where he makes the claim that CRUD is bad for REST. I couldn’t disagree more, so I felt it important to respond to his criticism.

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

Actually, they do map perfectly as CRUD itself is pretty simple (it’s literally create, retrieve, update, delete without caveats). The examples that are laid out in Arnon’s article are comparing REST directly to SQL Server commands. The question shouldn’t be do http verbs fit perfectly with SQL operations, but rather do they map to the four basic functions of persistent storage? I can say without any doubt that POST, GET, PUT, and DELETE map quite well, making it possible for REST useful for persistence.

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.

I see http verbs as resource oriented, and data is just one type of resource. Of course, if I’m creating an ADO.NET Data Service, I want to expose my data as more useful resources (e.g. a useful representation of a Customer rather than just the customer data).

However, the main reason CRUD is wrong for REST is an architectural one. One of the base characteristics [1] 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. […] 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.

I could think about protocols, but a useful one already exists (HTTP). I could think about externalizing my state machine, but that’s already taken care of when using a product like ADO.NET Data Services. If you are busy with inserting and updating resources, you probably have a resource oriented architecture which doesn’t miss the whole point of REST as it *is* an implementation of a REST architecture.

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:

  1. It circumvents the whole idea about "Services" - there's no business logic.
  2. It is exposing internal database structure or data rather than a thought-out contract.
  3. It encourages bypassing real services and going straight to their data.
  4. It creates a blob service (the data source).
  5. It encourages minuscule demi-serices (the multiple "interfaces" of said blob) that disregard few of the fallacies of distributed computing.
  6. It is just client-server in sheep's clothing.

1. ADO.NET Data Services provides a standard ORM that can be consumed by any application. That in itself is useful as a service (retrieve entities rather than data, mapping is hidden). However, one can provide business logic in that tier if one chooses, but I think that’s bad design.

2. Even with the most direct ORM, you’re still providing mapped objects rather than an internal data structure. If you have a well-thought out map, then you will be providing that instead.

3. You aren’t going straight to the data, you are utilizing entities. The service exists and can act as a gate keeper.

4. I don’t understand this complaint… the data source is a binary large object service? If blob is meant in another sense, my answer is that you only expose what you want to expose with ADO.NET Data Services.

5. I suppose I’ve never thought about setting up multiple demi-services?

6. The problem with client-server is the disregard of object-relational mapping and business layers. Even in the worst case scenario with ADO.NET Data Services, you get object-relational mapping.

I don’t believe CRUD is bad for REST at all. In fact, I believe they perfectly complement each other in the construction of a resource oriented architecture.

Note: Cross posted from KodefuGuru.
Posted on Wednesday, July 15, 2009 11:31 AM | Back to top

Comments on this post: Response to CRUD is bad for REST

# mature bisexual and lesbian
Requesting Gravatar...
My friend emailed me your post URL. I thought it will be something not worth my time, but I was wrong. Will tell my friend thanks.
lesbian dildo free
Left by Ignitte on Aug 23, 2009 4:24 PM

Your comment:
 (will show your gravatar)

Copyright © Chris Eargle | Powered by: