Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?