[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
作者：蒋金楠
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。