Monday, April 14, 2008

The Mighty ROA(R) of REST

I must confess I didn’t fully get REST until recently. Given the amount of interest around REST most people understand the basics:

  • It’s an architectural style. It’s not a technology itself, rather a set of well defined guidelines or rules for building scalable applications utilizing HTTP.

  • HTTP verbs such as POST, GET, PUT and DELETE are used to communicate desired behaviour to the server.

  • Each of these verbs have a well-defined CRUD actions associated with them i.e. POST = Create, Update, Delete; GET = Read, etc.

  • URIs are used to represent resources to act upon. The information that appears in URIs usually identifies Nouns such as{person} or{person}/addresses.

What I didn’t get until recently is how you build applications in a RESTful way. This was because my mind was still set in RPC mode. This means that I was trying to map RPC/WS calls to REST and quickly you start to think there aren’t enough verbs in HTTP to perform all tasks. The real problem was that in order to build a RESTful architecture you need to think in terms of Resource Oriented Architecture (ROA). That is you need leave behind the urge to define interactions in terms of ‘what you want to do’ and shift focus to ‘what resource you want to act upon’.

For example, you may have a Web Service that has a login() method. This is an action; it’s something you want to do. How does this map to resource? A resource needs to be defined where login() becomes an action on the resource. In this case it would be a UserSession resource. This may not be immediately obvious coming from WS/RPC world since the UserSession resource didn’t exist.

I am still getting to grips with some of the detail of ROA but I am becoming a big fan. I love the fact that RESTful proponents are very particular about REST terminology (apologies for any faux pas I might have made here), the power of REST seems to lie in the acceptance of a core set of principals; there is no room for ambiguity or bending the rules. This also means that REST is not suited for all architectures, but is certainly a powerful architecture style that should be in all architects toolbox.


antoine said...

Hi Ross,

Thanks for the simple and straight-forward explanation of REST; I must confess that I still didn't get it till recently (and probably haven't 'got' it fully yet either)

One question for you -
You talk about ROA since in the REST universe all things are resources. Would you map these resources to 'services' in an SOA? Or am I completely off-track?

andrew said...

2 antoine:

To answer your question about mapping resources to services - no, it's not always possible. That is, if you try to take an existing complex SOA and try reimplement it in ROA, the effort will give you hard times.

andrew said...

# Each of these verbs have a well-defined CRUD actions associated with them i.e. POST = Create, Update, Delete; GET = Read, etc.


There's still brushing up to do on your side, Ross. What you described is exactly what RPC architectures have been doing by overloading POST .

The correct mapping would be:

POST - create
PUT - update
GET - read
DELETE - delete


Ross Mason said...

Andrew, In theory, I would agree, but in practice mapping CRUD directly to verbs doesn't always work i.e. Stefan Tilkov and Simon Harris talk a bit about this.

Also, wikipedia seems to say otherwise.

I used to think the same as you, since mapping a single CRUD operation to a verb makes the concepts easier to understand, but it seems that in the real world this might be too simplistic.

Ross Mason said...

Antoine, good question :) In my current understanding it would seem many services such as 'Task' or 'Utility' services would not map to resources directly, but you would define one or more resources that represent what the service would act upon. 'Entity' services may offer more obvious resource mappings since they often represent an entity in the organisation i.e. Inventory System where the resources might be 'Catalog' and 'Item'.

Yuen-Chi Lian said...

I still have a question in mind about REST (I could have more questions), may because I haven't yet found the right resource to read.

Since REST promotes stateless communication, and say if you're accessing a bunch of resources which are meant to be protected, how will you validate your credential? Attached user/pass pair per each request? Get a token and send it per request? Or use Basic Auth?

(Alright, looks like this is something relevant)

- yc

Ross Mason said...

Yeun-chi, To be stateless means to pass information around the system. In the early days of ESB it was considered good practice to keep the ESB stateless and pass all state around in the message, headers or attachments. RESTful architectures work the same way by sending things like credentials for every invocation.