Now for the REST of the story
What is REST?
When boiled down, REST is an architectural style that defines a set of constraints. These constrains describe what HTTP and the World Wide Web are based on. These constraints can be defined as follows (list and image below used from A Brief Introduction to REST):
- Give every “thing” (resources) an ID
- Link things together
- Use standard methods
- Resources with multiple representations
- Communicate statelessly
Some example URIs that would be used to get resources:
http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554
http://example.com/processes/salary-increase-234
As you can see from the examples above a customer is accessed by an id (end part of the URI). It is important to note that a single item, like a customer, is called a resource in REST terminology. If you wanted to retrieve a list of all customers the list could be accessed by ‘http://example.com/customers’.
You interact with the resources with the operations GET, PUT, POST, and DELETE which are requested using HTTP request headers. The header methods are at base level CRUD operations. The implementer of the REST interface could decide to return result as XML, HTML, plain text, or any MIME type.
The following image is linked from the article mentioned above. This gives a great visual on how one could interact with resources or collection of resources.
Demo Site
I ran across a great site that had a hands on demo of REST. In the article the author goes through all the different operations (GET, POST, PUT, or DELETE) and it allows you to interface with a sample database he set up.
I downloaded the PHP code and adapted it to a project that I have been working on. It was very straight forward to set up and play around with. I was able to populate and edit the project’s database tables, including ones with complicated foreign key contraints. The code uses apache’s mod_rewrite module to redirect everything to the redirect all traffic to the index.php in the root of the site. The code then parses the remaining URL and converts it into a SQL statement depending on the operation that is in the request header.
When trying to consider limitation like security, complex data mappings, URL encoding, or meaningful error message (deeper than HTTP response codes) I asked myself ‘how does web application that I have seen and worked with handle that issue?’. Different ideas for solution came to me when asking myself the question. I think once you start using the web as the means for access there is a lot of tried and true means of dealing with issues that have been addressed historically. One could contrast the REST approach with SOAP which uses the web as a transport only. SOAP has gone through a lot of changes and is always in flux and in a lot of cases tied to the commercial provider that is implementing the toolkit for it’s use. The web has been around for a long time and the beauty of it is that nobody owns it and it really is only limited by the imagination of the developer implementing it’s interfaces.
It is definitely worth the time to play around with the demo on the article’s site and go through the short tutorial. It was definitely interesting to learn how someone could implement the interface by going through the code.
[...] have covered a couple of REST topics previously, Who Needs REST? and Now for the REST of the Story. I started playing around with a client library used to consume rest services and discuss the [...]