Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News unREST as the new REST?

unREST as the new REST?

This item in japanese

It's fair to say that the mere mention of the word REST causes polarisation in people. For a while REST struggled against the WS-* wave and then appeared to have surmounted that obstacle only to start to fall foul of those people who believe that there is a benefit to be found within REST but perhaps not as much as others might like to believe. One of the main advocates against buying in to the totality of what "RESTafarians" believe is Jean-Jacques Dubray, who recently published an article on what he calls unREST. As JJ begins:

Since 2007, the industry was told by a handful of people that the "Web" could teach us everything about distributed computing, and that everything we had done before was simply wrong. Four years later, we can only see that the emperor is completely naked

At the heart of JJs argument is that REST was designed with the browser in mind and any attempt to use it outside of this context is inherently unRESTful anyway:

REST was designed with an end-user in mind, operating a user agent: the browser [...]. Everything that has been written to apply REST principles to a software agent-to-server scenario is simply wrong. [...] It is time to move on from all this mind bending serendipitous complexity that brings absolutely nothing, except more lost productivity by forcing to everyone to hand code everything we got for free in previous distributed computing paradigms.

In JJs own words, REST "is just not applicable to the problem at hand" and "It's cool to be RESTless". So just what does this mean? Well JJ outlines some rules that you can follow, including:

  • Defining a domain specific uniform interface: "Don't be shy, forget the 4 little HTTP verbs, you can even define your own: Query/Do/Notify/Synchronize is a perfectly good one. It means that all methods in your Web API will be of type query, action, notification or sync request."
  • Specify messages: obviously for two endpoints to communicate with each other they must be able to understand the messages that are exchanged. But as JJ says "Explicit message definitions which can be explicitely versioned is essential to a healthy API definition. Message Extensibility is the property that makes distributed computing work."
  • Specify contracts between your endpoints and ensure they are versioned: both the interface between endpoints and the messages that are exchanged form part of a contract. JJ states that the approach of moving away from a machine-readable contract to something which is only human readable, is unworkable and believes that many hours have been wasted as a result. "A uniform interface is not enough to form a contract, it is only the substrate on which a contract is defined." JJ believes that the only way in which to build a "healthy ecosystem of Web API consumers" is to use machine reable contracts that are versioned to ensure evolution and reuse.

And that's it: with those 3 rules JJ believes we have a foundation for creating successful APIs. He points out that the post isn't based on mere whim: he has spent the last decade at least working on web-based protocols, including ebXML. So do you agree with these or with his last comment?

You are now free to unREST and laugh quietly at anyone who asks you to marvel at an HTTP header, a "link", use a 7 letter acronym, or tells you with the authority of a story teller that you don't get it. REST was just a (bad) dream, unREST is what you want to do.

With many people talking more and more about REST, particularly in areas such as Cloud, if JJ is right then is it too late to change these approaches, or are these groups inherently unRESTful already? Or perhaps unREST is harking back to the "bad old days"?

Rate this Article