It looks like terms such as cloud computing, SAAS, web services, REST, loose coupling and similar are popping here and there more and more often. Unlike in case of SOA big shmuzz buzz (see my favorite site on SOA) the above mentioned terms do have some meaning and can take some shape or form. Today the time to explore REST has come.
Intro
The definition of REST can be found in the number of places. Below I highlight only the things that I consider worth to emphasize.
REST (Representational State Transfer) is:
- Architectural style
- Architecture of the web as it is today.
Further REST:
- Enforces widely acceptable and understandable patters dealing with representation and access to the resources on the Internet
- Action performed and the resource must carry a representation of it’s state plus metadata
- The data carried with the request or response may be in different depending on the implementation for example XML (in case of AtomPub) or JSON etc,.
- If I understand correctly metadata should carry info about further possiblities of actions on the resource (metadata with JSON?)
Defining REST
The name of the resource that is and item to be manipulated is a noun for example http://unisalveo.org/food (if to return single entity) or http://unisalveo.org/foods (if to return collection). We can “stack” a number of nouns on top of each other for a example http://unisalveo.org/foods/newest or http://unisalveo.org/foods/drinks.
The operation that is to be performed on the item is a verb. There is a number of “out of the box” operations that can be performed on the given resource (noun) with HTTP protocol namely:
- POST – place new item as a resource
- GET – get the recource
- PUT – replace the existing item with a new one
- DELETE – remove a given resource.
- According to REST principles outlined by Fielding it should be possible to traverse the resources from one point without prior knowledge about the API specifics of this resource.
- It looks like Google returns JSON without new lines from its web services. Nice thing to do to preserve bandwidth.
- Fielding distinguishes between RPC based on URI and REST. For the moment it’s a bit blurry to me and I have a feeling that might completely change my view on the subject
. InfoQ has some discussion on the subject. Another good resource seem to be here. - There is a question about how to represent a particular type of service i.e. how to group nouns. Maybe just putting service in URI http://charts.unisalveo.org/piechart? Is there a need to PUT or DELETE? Maybe this given service should be used as cache that is updated (PUT) when applicable data changes. That sounds tricky but can limit the amount of dynamically (i.e. per request) degenerated content.
- Versioning of the particular REST web service is also important. It is potentially very easy to break the functionality of the system if data and matadata returned by the service changes without maintaining the previous version. In loosely copuled architecture is must be very hard to test all the dependencies especially in the case in which we do not control all the resources.
- It might be desirable to return different content types from different resources. Does the break some standards, protocols or patterns?
- It might be worth to explore having multiple URI schemes. Since I would like to use UUID for identification of most of the resources it might be difficult for human to read and find particular resource.
- There must be a way to describe which methods (verbs) are supported on different resources.
Those operations roughly correspond to CRUD database operations operations or COPY, PASTE OVER, PASTE AFTER, and CUT. It looks like it is encouraged to use only those verbs in order to perform the operation on the resources. I thought that it makes sense to build URI’s such as http://unisalveo.org/food/search but it looks like it is discouraged. It is better to add parameters (constraints) to GET request in order to limit the data returned by the server (are HTTP methods really enough for all the possible operations?!).
In addition, constructing the mixes of nouns and verbs in a single word in the URI, for example http://unisalveo.org/searchForFood, is also considered a bad practice.
Other findings
Some links
Roy Fielding Dissertation
REST Triangle: nouns, verbs and content type spaces
REST Methods (verbs)
RESTful searching
Google RESTful search API
RESTful Design
URL Construction
XML.com Resources on REST
Intro into the AtomPub by Google
Intro into REST by Google
I guess thats enough for today 
.
