Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I learned REST and it feels a lot like CRUD (from what I have read about CRUD).

I know they are different, and I wonder if thinking they are similar means I don't understand them.

Is it that REST is a "superset" of CRUD? Does everything CRUD does and more?

share|improve this question
1  
Thinking they are similar means that you do understand them. In reading the answers, I see a surprising and what I consider to be incorrect level of not acknowledging the similarities between the concepts. I believe that the correct way to understand REST is to think of it as "CRUD for HTTP resources". If you understand what an HTTP resource is (its not the same as a database record obviously) and you know what CRUD is, then describing REST as "CRUD for HTTP resources" is a correct and succinct way to convey the essence of REST. –  Jason Livesay May 7 at 8:30

4 Answers 4

up vote 42 down vote accepted

Surprisingly, I don't see in the other answers what i consider the real difference between REST and CRUD: what does each one manages.

CRUD means the basic operations to be done in a data repository. You directly handle records or data objects; apart from these operations, the records are passive entities. Typically it's just database tables and records.

REST, on the other hand, operates on resource representations, each one identified by an URL. These are typically not data objects, but complex objects abstractions.

For example, a resource can be a user's comment. That means not only a record in a 'comment' table, but also its relationships with the 'user' resource, the post that comments, maybe another comment that it answers.

Operating on the comment isn't a primitive database operation, it can have significant side effects, like firing an alert to the original poster, or recalculating some gamelike 'points', or updating some 'followers stream'.

Also, a resource representation includes hypertext (check the HATEOAS principle), allowing the designer to express relationships between resources, or guiding the REST client in an operation's workflow.

In short, CRUD is a set primitive operations (mostly for databases and static data storages), while REST is a very-high-level API style (mostly for webservices and other 'live' systems).

The first one manipulates data, the other interacts with a working system.

share|improve this answer
    
+1, I was about to link to HATEOAS too :D –  Cameron Nov 21 '11 at 3:49
    
@Javier Thanks for setting them apart. I used REST learning Rails and I got the impression it was a replacement for CRUD (which I learned about since... the name that is, I was already using it, just didn't know what to call it)... You turned REST vs CRUD from comparing 2 apples to comparing apples and oranges. Thanks –  Maudicus Nov 21 '11 at 5:44
1  
@Maudicus: i think it's very common, since RoR includes a CRUD layer (as most (every?) framework does), and it makes it easy (automatic?) to add a REST API on top of that, it's easy to think that's all what REST is. But then you can add functionality on top of CRUD but behind the REST API, making them more and more different. –  Javier Nov 22 '11 at 1:07
    
Your answer is correct, but the example isn't optimal: a comment can boil down to a single db row, and isn't it possible to implement dynamic changes to related objects with db triggers? I feel there's a little more than just crud operations in restful api though, and your answer clearly carry that feeling well. –  didierc Jul 21 at 6:42
    
So...same thing, different layer :) –  AlikElzin-kilaka Aug 8 at 12:08

First of all, both are simply common initials; they're nothing to be afraid of.

Now, CRUD is a simple term that was abbreviated because it's a common feature in many applications, and it's easier to say CRUD. It describes the 4 basic operations you can perform on data (or a resource). Create, Read, Update, Delete.

REST however, is a named practice (just like AJAX), not a technology in itself. It encourages use of capabilities that have long been inherent in the HTTP protocol, but seldom used.

When you have a URL (Uniform Resource Locator) and you point your browser to it by the address line, you're sending an HTTP request. Each HTTP request contains information that the server can use to know which HTTP response to send back to the client that issued the request.

Each request contains a URL, so the server knows which resource you want to access, but it can also contain a method. A method describes what to do with that resource.

But this "method" concept wasn't used very often.

Usually, people would just link to pages via the GET method, and issue any type of updates (deletions, insertions, updates) via the POST method.

And because of that you couldn't treat one resource (URL) as a true resource in itself. You had to have separate URLs for deletion, insertion or update of the same resource. For example:

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

With REST, you create forms that are smarter because they use other HTTP methods aside of POST, and program your server to be able to distinguish between methods, not only URLS. So for example:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

Remember, a single URL describes a single resource. A single post is a single resource. With REST you treat resources the way they were meant to be treated. You're telling the server which resource you want to handle, and how to handle it.

There are many other features to "RESTful architecture", which you can read about in Wikipedia, other articles or books, if you're interested. There isn't a whole lot more to CRUD itself, on the other hand.

share|improve this answer
    
That it clears it up. Thanks a bunch! –  Maudicus Nov 20 '11 at 18:40
3  
sorry, but REST is a lot more than CRUD. mostly because resources embody a lot more than a single record each, and each operation does a lot more than updating a record. –  Javier Nov 21 '11 at 3:23
2  
Ok. I agree. Why are you sorry? I didn't say that it wasn't a lot more than CRUD. I think that's exactly what I did say. –  Yam Marcovic Nov 21 '11 at 17:36
1  
This should be the right answer. –  Brandon May 9 at 16:11

REST stands for "representational state transfer", which means it's all about communicating and modifying the state of some resource in a system.

REST gets quite involved, because the theory behind REST gets into leveraging media, hypermedia, and an underlying protocol to manage information on a remote system.

CRUD, on the other hand, is a mnemonic for the common operations you need for data in a database: Create Retrieve Update Delete. But it really doesn't get any deeper than that.

So that's the answer to your question, but I'll mention the common mistake I see when REST and CRUD are discussed together. A lot of developers want to map REST to CRUD directly, because REST over HTTP provides for GET PUT POST and DELETE, while CRUD provides for CREATE RETRIEVE UPDATE DELETE. It's natural to want to map the REST verbs directly to CRUD operations.

However, HTTP uses a "create or update" style, while CRUD separates create and update. That makes it impossible (!) to make a clean, general mapping between the two (!)

GET and DELETE are easy... GET === RETRIEVE, and DELETE === DELETE.

But per the HTTP spec, PUT is actually Create AND Update:

  • Use PUT to create a brand new object when you know everything about it, including its identifier

  • Use PUT to update an object (usually with a complete representation of the object)

POST is the "processing" verb, and is considered the "append" verb:

  • Use POST to append a new object to a collection -- that is, create a new object

  • POST is also used when none of the other verbs quite fit, as the HTTP spec defines it as the "data processing" verb

  • If your team is getting hung up on POST, remember that the entire WWW was built on GET and POST ;)

So while there is similarity between REST and CRUD, the mistake I see most teams make is to make an equivalence between the two. A team really needs to be careful when defining a REST API not to get too hung up on the CRUD mnemonic, because REST as a practice really has a lot of additional complexity that doesn't map cleanly to CRUD.

share|improve this answer

CRUD specifies a minimal set of basic storage verbs for data reading and writing: create, read, update and delete. Then, you can build other operations by aggregating these. These are usually considered database operations, but what is considered a database is arbitrary (e.g., could be a relational DBMS, but could also be YAML files).

REST is an "architectural style" that usually includes CRUD operations and other, higher level operations, all to be performed on some concept of "resources" (arbitrary, but these are entities in your application). REST has a bunch of constraints that make it interesting (and particularly well-paired with HTTP).

A REST interface can, but doesn't have to, expose all CRUD operations on a particular resource. What is available in a REST interface is arbitrary and may change due to system permissions, UI considerations, and how hot it was on the day the interface was designed and created. Hotter days lead to more minimalist interfaces, usually, though the opposite can be true.

share|improve this answer
    
Thanks Yar. It seems my "Does everything CRUD does and more?" is a yes, with a technicality of REST applies to more than just entries in a database. –  Maudicus Nov 20 '11 at 7:06
    
@Maudicus I updated the answer, but to be specific: it can but does not HAVE to. –  Yar Nov 20 '11 at 7:07
    
I wouldn't say that they're required for your application to be considered complete. Some applications don't need insertions, removals or updates, by nature. –  Yam Marcovic Nov 20 '11 at 7:37
    
@Yam Marcovic, okay, adjusted –  Yar Nov 20 '11 at 8:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.