Since our kids were born years ago, my wife has generally been pretty Organic crazy.  The Organic food movement was created so that we don’t “poison” our bodies with food grown and treated with harmful pesticides and chemicals, that don’t introduce dangerous genetically modified seeds or growth hormones, and finally, contribute generally to society as a whole by promoting sustainable farming that doesn’t deplete or damage the environment.

From Movement to Certification

Organic food and farming started out as a movement, but quickly turned into a branding and certification effort.  Many farmers and companies found that following strict organic principles was expensive and added to the cost of the goods they produced.  While many customers were willing to pay the extra cost involved to avoid “poisoning” their bodies, still many others are more interested in saving money now and worrying about the long term consequences to their bodies and environment later down the road.  So, some companies would avoid pesticides, but still use genetically modified seeds, and call their products organic.  Or milk companies wouldn’t use growth hormones, but still use non-organic feeds for their livestock, and still call their products organic.

To fight this pollution and misrepresentation of organic principles a branding and certification effort was introduced so that each product on the market could be officially approved as organic or not.  Organic food customers would know what to expect from a product by seeing this brand on their packaging.  If you wanted to sell organic products, you’d have to be officially certified and inspected by a third party.

Is REST following Organic’s path?

Roy Fielding, the father of REST, has the same expectations that organic food consumers have.  When something is deemed RESTful he has certain expectations that have to be 100% fulfilled.  Its very understandable as Roy deals with Web standards, they have to scale, their going to be used by millions.  The stability and usability of the Web are too important to propagate flawed protocols.  Roy says in his PhD:

While mismatches [to REST] cannot be avoided in general, it is possible to identify them before they become standardized.

So, maybe Roy should trademark REST, brand REST, and promote the creation of an official organization that can bless an application or API as RESTful much like we have an Organically Certified label.  Let’s do a tiny thought exercise on this…

One of the consequences of heading down this route is that REST evangelists will lose the Web as their prime example of REST in action.  While the HTML and HTTP standards and specifications will be a great example of REST in action, most of the applications on the Web don’t follow the strict criteria of REST (a static web page is not an application).  As Roy states, its hard to avoid mismatches in the RESTful style, even if you try.  This is especially true if you’re building a distributed interface for a legacy system.  The rest of us will lose a lot of language and vocabulary to describe our apps if REST is branded/certified.

Well…You may be laughing (or fuming) about the idea of branding and certifying REST.  The thing is though, often, when you interact with the REST community you get condescending comments like:

Then do not call it REST. It is that simple. And saying that some academic has not written a line of code detracts from what you are saying. REST has a clear enough definition. XXXX  (insert whatever here) is not RESTful, so don’t call it so!!

You get this sort of interaction when a thought, API, or interface breaks or bends a RESTful principle AND you want to still use REST to name and/or describe your thing.  Reactions like this is very akin to treating REST as a certified brand rather than a style.

Expectations are just not the same

The thing is though, the expectations of IANA, W3C, and people Roy Fielding are very different than the average application developer.  There’s really two main reasons why a developer initially is attracted to REST:

  • Simplicity.  You can use a RESTful interface without having to define a WSDL document, generate stubs, and download (or pay for) some complex middleware stack or library just to implement a “Hello World” example.
  • “Lightweight” interoperability.  Because HTTP is everywhere, if you write a RESTful interface, it should be usable in most languages and platforms without much effort (i.e. iphone, android, python, Ruby, Java, Perl, etc…)

Sure, there are a lot of other goodies you get when you learn more about REST architectural guidelines and start applying them, but these two reasons, IMO, are the reason app-developers initially look into REST.  W3C, IANA, etc. have different expectations, though, as they are defining standards that the Web will be built upon.  A screwup here can have a much more far reaching affects on things compared to messing up an application that can usually be refactored over time.  The domain REST is going to be applied to should have a direct correlation on how critical we should be of the interface.

Focus on benefits and consequences instead of definition

While strictly following REST works for Web standards, its just not always feasible to follow them religiously in everyday applications.  After all, REST is a style and set of guidelines, not a set of laws or, gasp, a branded certified trademark.  Instead, people should be allowed to use REST to name and describe themselves without harassment.  Instead, critics should focus on the consequences of a specific app or API not following a specific RESTful constraint and the benefits if they did modify the interface to follow the guideline.

I think we’ve all had negative experiences with trying to follow an architectural principle (REST, OOP, or whatever) religiously.  I think most of us realize that focusing on delivery to market through multiple iterations and user requirements and feedback is much more important than whether we religiously follow a specific guideline.  The easy answer is “Then don’t call it REST!”, but we’d have a very limited vocabulary in software engineering if this mantra was followed with every new architectural style that was created.