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 it do everything CRUD does and more?
Surprisingly, I don't see in the other answers what I consider the real difference between REST and CRUD: what 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 object 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 comment is attached to, maybe another comment that it responds to.
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 game-like '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 web services and other 'live' systems).
The first one manipulates basic data, the other interacts with a complex system.
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.
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.
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.
CRUD
REST
REST stands for Representational State Transfer.(It is sometimes spelled "ReST")
It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used
REST is an architecture style for designing networked applications
REST is something like a webpage for machines, which they can browse, while CRUD is something like SOAP, which is strongly coupled to its clients. These are the main differences. Ofc. they are similar on the surface, but CRUD describes basic entity manipulation, while REST can describe the interface of any application. Another difference that REST can use more the 4 HTTP methods. It would be a very long answer if I'd want to collect all the differences, if you check the questions about REST vs SOAP, then you will find most of them.
I think confusing REST with CRUD is a very common mistake and the cause is that developers don't have the time to read about REST in depth. They just want to use the technology - without understanding it - based on limited CRUD style examples written by similar developers. The vast majority of the examples and tutorials are reflecting serious lack of knowledge. Mapping REST resources to entities and HTTP methods to CRUD operations of these entities and using REST without hyperlinks is just a symptom of that. By REST you map hyperlinks (including links with POST/PUT/DELETE/PATCH methods) to your operations and you identify the operation on the client side by checking the (usually API specific) link relation. If a REST client does not know what a link relation is, and knows only the HTTP methods and maybe some URI templates, then that is not a REST client, but a CRUD on HTTP client. Another common mistake that a REST client is a single page javascript application running in the browser. Of course you can implement such a client, but REST was meant mainly for automatic clients (server side applications written by developers you don't even know) and not for manual clients (user controlled browser applications written by you). Having only a single browser client might be a sign that you don't really need REST and you just overengineered the project. In these cases a CRUD API is a viable solution and developers are calling these CRUD APIs as REST, because they don't know the difference.
