REST maturity - 3 levels

Approaching the REST API implementation, there are some inaccuracies among programmers community. Some of them publish an API called REST which is in fact not REST because it violates some of it's constrains.

Leonard Richardson discussed "The Maturity Heuristic" at 2008 QCon speech. This can be viewed as levels of REST, or maturity levels of REST, or simply maturity of REST. I'd like to present my summary of his speech:

Level 0:
One URI and one HTTP method:
client can communicate with web app only through one URI, using only one method. This is like SOAP. We are using HTTP protocol here only as a container for our messages which carrying all the control information in the HTTP body.

Level 1:
Many URIs and one HTTP method:
it is level 0 with extended possibility - address concrete things. It's giving us opportunity to use only part of such web app (by addressing concrete thing through its URI) if we want. But we still have to put control information into HTTP body if we need further actions over URI.

Level 2:
Many URIs, each supporting multiple HTTP methods:
we can address desired resource and we can tell what to do with that resource by using HTTP verbs only. In the body there are no control information allowed. It can contain only content for addressed entity.

Level 3:
Many URIs, multiple HTTP methods and resources describing their own capabilities and interconnections:
if you enter some resource, it not only tells you what can you do with it. It tells you what are the actual URIs of possible actions, even what are the actual URIs of relevant elements(other URIs) and their actions. This is something called HATEOAS.
Best thing about level 3 is that you don't need manual to use it or to write client for that. You actually doesn't need to write client which is specific for some webapp because generic client can use all webapps which are at level 3.

So which of these mentioned levels belongs in REST?
The original author of REST, Roy T. Fielding clarifies common mistakes about REST API on his blog. He is very restrictive about what is REST and what's not - no levels allowed. If we apply his rules to levels above we can tell that only level 3 is REST. The other levels are not. So API which is below level 3 are not RESTful.

Summary of some publicly available REST APIs

Below is list of some publicly available REST APIs (or APIs close to REST). I am going to take a further look at them. Any suggestion for another interesting REST API is welcome.

• API for Amazon S3 (Amazon Simple Storage Service),
• API for Google Cloud Storage,
• API for PHPRESTSQL (A HTTP REST interface to MySQL written in PHP),
• API for Dropbox,
• API for bitly,
• API for goo.gl,
• API for Myspace,
• API for Netflix,
• API for Twitter,
• API for SalesForce,
• API for delta cloud,

Thats all for now. The ordering in list is random.

Motivation for programing the RADREST framework

The server sides of today's Internet applications are very similar. Of course, every app is different by it’s functionality and complexity. They typically follow the MVC pattern using some existing framework providing desired business functionality. The applications contains a lot of similar source code. It runs on own server and it’s hard to use by other web apps. The development and maintenance must be made by experienced programmer.

What is typically the purpose of such applications? It’s processing data! More formally we can say that it’s purpose is exchanging representation of information. Do we really need to do so much server side programming? Why should programmers repeat the handlers coding instead they should focus on desired functionality? The only thing we need to know is where on the web is the needed information. If we knew where to find it, we can easily read it or modify it. Our believe is that we can design desired business functionality putting together couple of REST services. The resources can be ours or provided by 3rd party companies. We also want open the door to non-programmers providing simple server side REST assembly environment.

Our approach offers several advantages for web applications designers. The end users would be able to easily develop and publish the desired business functionality without deeper programming knowledge. Programmers on the other hand would be able to assembly even very complex applications really fast and easy. And maintenance of such apps will be also simplified. There won’t be any server side programing. As for apps, there are also several advantages. For example, moving apps from server to server wouldn't be any problem anymore. Creation and deployment of an app will be matter of few clicks. An app that obeys REST will be easily scalable.

The user owned REST services will be provided to third parties applications. They will serve external application, without knowing the implementation details. This is opening new business with the REST based services. Big corporations can create REST services exchange or replace dozens of Informational Systems they already used.

These are the reasons why we believe we need to move from object oriented programing (OOP) to resource oriented programming (ROP) and facilitate it’s easy deployment on server.