Never a dull moment at Devoxx ’08 this year, particularly the well-prepared session by Stefan Tilkov about REST (or, to be precise, about RESTful HTTP). Stefan is quite the REST advocate and talked to us about some anti-patterns and patterns to use when building RESTful HTTP applications. I’ve been trying to get to grips with REST for awhile (Dan Diephouse‘s been doing a good job of this) and this session certainly helped
The way I read things, the following rules are required for a RESTful application:
- In REST, everything should have an ID. Every item, every resource, every single unit of whatever it is you’re working with should have a usable ID and everything should be referred to by this ID. This seems like it is common sense but I have been in situations where this is not the case. I wondered if I was the only one thinking this but since no one else sniggered at the slide, perhaps I was.
- These IDs should be used everywhere in hyperlinks to let items link to one another. This is kind of cool and I never thought of doing things like this. It would be simple for me to build a Mule application that returns customer data in XML format and which would link to, say, http://myserver:8080/orders/1234 to refer to a specific order. This URI would then refer to a service in Mule that knows how to retrieve this order from wherever it is stored.
- Standard methods should be used – Stefan talked about RESTful HTTP specifically and therefore focused on GET, PUT, POST, DELETE. I’m not sure if I can translate this into Mule terms or if I even should be trying to. I think that this can be done, but I’m not sure if my thoughts would result in overkill or not.
- Have multiple representations of data so that a client can ask for the HTML version of a resource or an XML version of a resource or whatever it’s comfortable handling. This is a neat feature and something I never really thought of. Whenever designing Mule applications, I always thought of different representations separately as typically I’d be working with e-mail, XML, HTML and would therefore use SMTP, file and HTTP endpoints rather than one endpoint that can support all formats. I like this idea but, again, am having trouble converting this to Mule-speak.
- Stateless communication allows your application to scale better. I cannot agree with this more. There are some instances where a Mule application can keep state but then scalability is always an issue. The idempotent router is a good example of a stateful element in Mule that would hinder scalability.
My mental blocks are points 3 and 4 above – should I be translating everything into Mule terms? Is this overkill or is it possible, desirable even, to have a RESTful Mule?