RESTful SOA patterns

At the SD Best Practices conference, Dan Diephouse of MuleSource gave a talk about Patterns for RESTful SOA. We discussed this subject prior to his talk.

While most of the software development world's attention was on the Microsoft PDC in LA, another group of software development conferences was going on in Boston, including the Embedded Systems Conference and the SD Best Practices Conference. Dan Diephouse of MuleSource gave a talk at the latter about Patterns for RESTful SOA, and gave me a call to talk about it. He also provided a PDF of the talk, which I have posted for your viewing pleasure.

[ Download Dan's presentation (PDF, 1.2 MB) ]

galaxy_overview.gif

Diephouse is the chief software architect for Mule Galaxy, MuleSource's SOA governance platform. If you look at the Galaxy architecture in the figure above, you'll see a piece called HTTP/AtomPub RESTful API. Dan's talk shares some of the lessons learned in developing that piece of the product.

Why bother giving a talk like this at all? According to Diephouse, many companies are not familiar with RESTful architecture and tend to trip over common problems. REST is of course an acronym for representational transfer, and basically refers to the URI addressing scheme for resources and GET/POST/PUT/DELETE/HEAD verbs that underlie the HTTP protocol and the Internet.

By the way, if you aren't familiar with RESTful architecture, I recommend RESTful Web Services, by Leonard Richardson and Sam Ruby (O'Reilly, 2007, 446 pp., $39.99). As a matter of fact, Diephouse does, too, along with RFC2616.

9780596529260_cat.gif
By the way, if you aren't familiar with RESTful architecture, I recommend RESTful Web Services , by Leonard Richardson and Sam Ruby (O'Reilly, 2007, 446 pp., $39.99). As a matter of fact, Diephouse does, too, along with RFC2616 .

Getting back to Dan's talk, he points out a number of issues of which anyone doing SOA, and especially RESTful SOA, should be aware. One is event-driven architecture, which can choke the pipes if the events are too frequent: in that case, it makes more sense to use a polling request/response architecture. Another issue is the sheer size of the Web services stack that many people use, when REST could be done with much less overhead, much more easily, and be just as reliable.

Then there are data formats. The common problem here is that people start with bare XML and then grow their own schema, when starting with an existing schema with existing libraries would speed the development immensely. For example, Atom instantly provides a framework for data, metadata, and hypertext, and is supported by AtomPub and Apache Abdera. JSON is another example of a superior data format that already exists and is fully supported in most languages.

Another point that Diephouse makes is that XHTML is superior to HTML because it includes facilities for metadata. And finally, Diephouse touts caching and ETags as cures for excessive repeated transmissions of data in response to GET requests.

Copyright © 2008 IDG Communications, Inc.

How to choose a low-code development platform