I've read a fair share of blog posts and comments about how REST is just SQL reinvented. It's the same old CRUD as bedore. Time to debunk.
Note that I refer to HTTP all the time, I'm actually meaning strict REST HTTP, not SOAP over HTTP or XMLRPC over HTTP.
The obvious case for comparison is the four verbs of REST:
People who presumably don't understand REST say that this is exactly the same as SQL's four DML verbs
Now this comparison is fairly easy to make. But it's plain wrong. The four verbs of the SQL DML mean something completely different than the so-called counterparts in REST. Here's how they differ:
HTTP GET retrieves some data, yes, but it simply retrieves a single representation of a resource (and typically, the complete representation; not a smal part of it). SQL SELECT on the other hand can be wielded to extract different parts of lots of resources, join together records in many different tables. A HTTP GET could be mapped to a selection of a single row in a single table. SQL SELECT * FROM SOMETABLE WHERE ID=1234. GET just isn't what SQL SELECT is.
GET is also a lot more powerful; in a single request it can authenticate itself, identify exactly the resource that it wants, what type of representation it wants, what language, encoding and so on, and even what type of compression may be used. If there are intermediaries such as caching proxies in the mix they can (in the same request/response) ensure that their caches are up-to-date, and even serve the content from their cache without even asking the real server. SQL SELECT is built for a completely different problem, and can't be compared. It's like comparing apples and ... not apples.
This is where the analogy really starts to fall apart. UPDATE is simply overwriting one existing records in a table with a new value. PUT on the other hand is a way to store a named resource. It's more like "File -> Save as..." in a desktop application. You may choose to save over an existing file, but you may also choose to create a new one. HTTP PUT handles both cases; both Create and Update.
Like GET, PUT is equally flexible when it comes to what it can do in a single request. Of course, it is limited to modifying a single resource, but it knows the difference between "create this if-and-only-if it doesn't exist" and "update this if-and-only-if it exists from before". It can also do "update this if-and-only-if it currently looks like this" (optimistic locking).
Like PUT, DELETE also operates on a single named resource, but otherwise, delete in HTTP is a lot like delete in SQL... But how different can DELETE be? Well, HTTP DELETE offers the same set of flexibilities, like "delete if-and-only-if it looks like this"
This is the most misunderstood method of them all. The SQL INSERT verb is well defined. It creates new records. However, the HTTP POST verb is completely undefined. According to RFC 2616, POST is to be used to create subordinate resources implying some sort of hierarchy, and lists some examples:
Ok, so the spec is rather dated. But the general idea is "submitting data to a data handling process" -- an idea which is quite different than the strictly defined SQL INSERT create new records.
POST is the most flexible of the four methods. It's like a potato, it can be used for anything. It's also the least powerful, since nobody can make assumptions on what the side effects are of a POST. GET, PUT and DELETE are well defined, and it's well defined what's expected to happen when you invoke those methods on a resource, whereas for POST, you'd have to check with the documentation for the resource.
As you can see the verbs of HTTP are quite different than the verbs of SQL -- they simply do different things.
This is another area in which SQL and REST are completely different. While we agree that all pieces of data need a unique identifier, and that it must be possible to refer to that unique key elsewhere, that's about all that there is agreement upon. SQL unique keys are only unique within the table they are defined. HTTP URIs (Uniform Resource Identifiers) are universally unique (the U in URL used to mean Universal). A SQL key has no meaning if you also give it some context (the name of the table or view, the name of the database, schema, server, port number, and so on). A HTTP URI identifies a resource without any context.
Yet again the two concepts are so wildly different it's hard to understand how people can assume they are at all alike. First of all, SQL foreign keys are limited to a single data store of some type, typically a single database schema, whereas hyperlinks are unrestricted. Secondly, SQL foreign keys can be enforced with referential integrity, whereas hyperlinks can't. Thirdly, SQL foreign keys can only (usefully) point to other records, whereas hyperlinks can point to anything, even abstract concepts which have no representation.
Hyperlinks also play a completely different role than foreign keys. Foreign keys are defined in the schema: The value CUSTID always refers to the ID field of the CUST table. You can ask the database schema for these things. Hyperlinks don't follow a rigid schema. Hyperlinks are just there, and point to other resources. Hyperlinks are used to discover these relationships. You can't go anywhere and ask if resources of a certain type generally have hyperlinks to resources of a different type. They just have them or they don't. If you want to know, you have to look at the resource yourself to see if it has a link to anything. If you want to act on that you can follow the link (if you can) and discover that resource. The concept of resource discovery is important in REST, since it removes the requirement of clients having a priori knowlege of how resources are linked together.
REST isn't a lot of things, and it certainly isn't SQL for the web!