chronicle of a curious mind
Tech, Internet, Life, Journey

Although SOA is a buzz word more often cited in enterprise application context, SOA also applies in Internet web application context. This is where RESTful web service comes into play. Most web2.0 websites are building sort of RESTful web services for mashup application development. However, many claimed RESTful web services are not RESTful at all, which have made REST father Fielding a bit frustrated. Maybe some guys just don’t want real RESTful stuff, so they kinda relax a bit. Fielding also talk about what we get if we relax REST style. The point is there is no high REST or low REST. You can only be RESTful or not. There is no middle ground.

If there are some misunderstanding about REST, here are the basic constraints specified by REST style:

• Resource oriented: each resource may have multiple representations. Resources are nouns in the vocabulary of systems. In http, it is about MIME types and content negotiation(Accept header).
• Unique identification of resources: each resource has an unique identifier. In http, it is about assigning URI to resources.
• Links between resources: resources should be linked so that agent can navigate from one resource to another. In http, it is about building hyperlinks between resources like sitemap.
• Uniform interface: Not like we specify a contract with programming langueage interface, REST requires an uniform interface for all kind of resources. In http, the interface is a fixed set of verbs: GET, POST, PUT, DELETE, which can be nicely mapped to CRUD operations in applications.
• Statelessness: Yes, REST is stateless. Even though we use session or cookie in http overwhelmingly. That’s the wrong way for scalable distributed system.
• Layering: you can plugin some kind of intermediary like proxy or cache or authentication between client and server. It is like adding some filters in between if you like.

If this summary is just too boring to read, you can refer to real-life examples of RESTful web services. Sun has published its RESTful cloud API with json MIME type. Google Gdata API is another good example with Atompub protocol.

If you are already familiar with REST stuff and want to go for it, please read this IEEE article on the best practices of developing RESTful web services by Vinoski.

Here is my take on how to develop RESTful web services:

1. identify resources you want to expose and build a resource model like SUN cloud API resource model. E.g. building a resource model for a bookshop: shop, room, book, category, review, shoppingcart, order, bestsellers, featured, discount
2. select an MIME type, json or Atompub or customized xml, to specify representation for each identified resource. E.g. specifying representation for the shop resource in json format:

   Content-Type: application/vnd.com.myshop.shop+json

   { “name” : “xxx shop”, “url” : “http://www.xxxshop.com”, “rooms”: [{"name" : "science","url" : "/science"},{"name" : "management", "url" : "/mgmt"}], “shoppingcart” : “/user_id/cart”, “order”:”/user_id/order”, “bestsellers”: [{"name" : "best 1", "url" : "/book/1"} , {"name" : "best 2", "url" : "/book/2"}]}

3. now we have resources and representations of resources. In other words, we have nouns. So what do we do next? Yes, verbs. We should attach verbs to nouns for interface definition. E.g. for resource book, user can GET and can not POST/PUT/DELETE. Maybe adminstrator can do update operation. But for resource review, user can GET/POST/PUT/DELETE.
4. we get a quite good RESTful interface, but not implement it yet. So we have to choose a convienient programming language to implement the interface. In java, maybe jersey is the best choice. Ruby has quite good support for RESTful web service by ActiveResouce package.

If I get enough time, I will make a complete example of RESTful web service design using online bookshop as demo application.