Rest Is Just Sql Reinvented

Take a look at these definitions:

The REST hypothesis is that the semantics of HTTP constitutes a coordination language which is is sufficiently general and complete to encompass any desired computational communication pattern. I.e., the hypothesis is that GET / PUT / POST / etc. can provide all coordination semantics between discretely modeled units of programs
The SQL hypothesis is that the semantics of RelationalAlgebra constitute a language which is is sufficiently general and complete to encompass any desired computational communication pattern. I.e., the hypothesis is that INSERT / SELECT/ UPDATE / DELETE. can provide all coordination semantics between discretely modeled units of programs

Is the similarity just a coincidence?

"[A]ny desired computational communication pattern" is a gross exaggeration of what REST and SQL support.

REST is not a standard, nor a protocol, nor a language. It is a collection of characteristics that may or may not be present in a distributed system. HTTP, as it is typically used, is one example of REST. Arguably, SQL (as it is typically used, not the language itself) is another. The HTTP protocol and the SQL "protocol" have similar RESTful characteristics, as follows:

Client-Server -- consumers (clients) "pull" representations from servers.
- HTTP: clients (typically Web browsers) "pull" representations (HTML) from HTTP servers
- SQL: clients "pull" representations (table contents, or derivations thereof) from DBMSes
Stateless -- no context is stored on the server.
- HTTP: Yes. Inherent in the protocol, though cookies and other mechanisms may be used to provide context.
- SQL: Maybe. Queries and single updates can be executed in a stateless fashion, but persistent connections and the associated transactional boundary are essential for keeping the integrity of the data when more than one statement execution is needed to alter the database.
Cache -- responses must be capable of being labeled as cacheable or non-cacheable.
- HTTP: defined in the protocol
- SQL: No. Not part of the language, but query/result caching may be performed by the DBMS or facilities external to the DBMS. Lack of support in this area, let alone standardisation, is sometimes a significant issue.
Uniform interface -- all resources are accessed via a generic interface.
- HTTP: GET, POST, PUT, DELETE. These are standardised.
- SQL: SELECT, UPDATE, INSERT, DELETE. These are conceptually standard and a SQL standard exists. Unfortunately, the standard is largely ignored and language specifics vary from DBMS product to DBMS product.
Named resources -- the system is founded on named resources.
- HTTP: URIs
- SQL: database, user, table, etc. names
Interconnected resource representations -- clients progress from state to state based on representation contents.
- HTTP: resources are interconnected using URIs
- SQL: table contents can drive state changes; interconnection can be provided by DBMS metadata catalogues, table names stored in tables, etc.
Layered components -- intermediaries can be inserted between clients and servers to enhance performance, support security, etc.
- HTTP: Proxy servers, cache servers, gateways, etc.
- SQL: Query caches, database abstraction layers, etc.

The similarities between the two are probably a natural result of designing distributed systems for minimal coupling, relative simplicity, and maximal opportunity for standardisation. If you were going to build a distributed system from scratch, whether to exchange documents (HTTP and the Web), facts (SQL and DBMSes), or something similar, a RESTful style -- whether you'd heard of REST or not -- would be a probable outcome of rational engineering for certain categories of distributed application.

However, a RESTful style will be a result only if the designer is concerned mostly with exchanging 'static' things (like documents, snapshots of facts or state, etc.). If the designer is concerned more about systems that are continuously updating, changing, and interacting, then one is more likely to see either PublishSubscribeModel (such as DataDistributionService), DataflowProgramming, or some other style more suitable for realtime low-latency updates, EventDrivenProgramming, and potential DeltaIsolation. Further, if data fusion of large data streams or command-and-control under disruption tolerant conditions are required, then even the above models won't fully suffice: one really needs the ability to embed agent services near the remote resources, and thus upgrade protocols and remote services on-the-fly in ad-hoc manners, to accommodate hostile and resource-limited network conditions.

A RESTful style comes from a set of assumptions that hold less and less well as systems become ever more interdependent. Can't tell you the number of times I wanted SQL to push realtime insert/delete/update modifications back to subscribers to ad-hoc queries...

For more about SQL see also ReinventingTheDatabaseInApplication, RestArchitecturalStyle, RestArchitectureDiscussion, EmbraceSql, KissWebServices

For more about X is Y see also ApiIsLanguage, DomainSpecificLanguage, GeneralApi, GreenspunsTenthRuleOfProgramming, GreencoddsTenthRuleOfProgramming

See OpenDataProtocol for a possible practical realworld example of RestIsJustSqlReinvented...

AugustZeroSeven, MarchZeroNine