REST-*, oh my … They Dared!

In an attempt to “standardize” REST a little more, Red Hat is launching an open alliance and community towards creating standards for RESTful Web Services (hem aren’t RESTful Web Services already implemented using some standards like… HTTP :-)) Of course this is of interest to our Web of Things community since we definitely foster the use of REST towards a architecture to integrate things to the Web (see paper and that whitepaper for instance).

However it seems like the REST-* initiative is also generating a lot of unhappy people amongst the RESTians. One of the reason is that they fear the REST-* initiative being a generated WS-* initiative (which is pretty much the case, JBOSS is an Enterprise Server after all, not a Web Server…) will end up with lessons like: “look guys, we did great stuff in the WS-* world now let’s apply what we know to the REST world”.
Fundamentally this would of course be wrong. If the initiative really takes off (which I quite doubt looking at the virulent feedbacks) then it is a great opportunity to rethink the WS-* integration patterns and not re-do what was done for WS-* in REST.

Essentially the first goal of such an organization should be (and is probably going to be, let’s hope) to educate people on the RESTful philosophy. Because it is definitely not trivial to entirely master (while trivial to use) and takes a while to fully understand. It probably took me over a year to go from “REST is just about URLs and Verbs (PUT, POST, etc.)” to “REST is really an architecture with constraints and great great benefits when you are interested in making you application PART of the Web”
REST is simple to use for the RESTful “API” (as word that RESTians don’t always love…) user but hard to grasp in a correct way for the RESTful “API” architect or developer.

So please REST-* guys and gals, do not do standards for the sake of it. The WS-* galaxy has so many standards that no one on earth can tell me how many (watch you eyes if you click on that). REST-* is a great idea which could turn so wrong, don’t waste it!

Indeed, there is a need to clarify what RESTful Web Services (which go beyond REST only) are about and this organization may help towards this particular goal. As a starting point what really helped ME towards this goal already exists. It is a book (a thing with a lot of pages that you can read without Internet connectivity) by people who understood most points of a RESTful architecture. A book that I read over and over again, understanding each time a little more while putting it in practice.

Btw, we are currently writing a more techie and scientific article for a conference which we will publish as a more detailed white paper once it is ready. It should also give its share of advices on building RESTful architectures for… things!

  • Btw, what do you guys things about REST-* especially when thinking about REST on devices? Shall we ask them to create a “REST for things” task force, or maybe actually… not! 😉

  • Hi, Dom.

    Obviously you know that I’m a fan of REST-ful interfaces, since Lighthammer was built on that foundation. That said, I am NOT a fan of restrictive “standards” in this particular case. Part of the beauty of REST-ful interfaces is their flexibility and adaptability for a wide range of purposes. I would, however, like to see a simple and consistent mechanism for querying a REST-ful service for its “metadata” and usage documentation.

  • Dear Rick,

    That said, I am NOT a fan of restrictive “standards” in this particular case.

    I’m with you on that one… Besides, why should we standardize what is already quite well standardized (e.g implementing REST with HTTP, a … standard!).

    I would, however, like to see a simple and consistent mechanism for querying a REST-ful service for its “metadata” and usage documentation.

    That’s completely relevant to us as well! In the case of smart things for instance we’ve felt, through our implementations and prototypes, a need for some kind of standardized discovery and description mechanism, something like the metadata of DPWS but focusing on “What does that service offers (semantics) and how does it offer it (invocation syntax)?”

    This would go beyond discovery by hypertext and help understanding some of the semantics of RESTful services.

    We are currently experimenting with the use of several techniques and languages such as the use of microformats or RDFa for example but haven’t found anything completely satisfactory yet…