The REST bubble

Just yesterday I was writing about how Cloud APIs are like military parades. To some extent, their REST rigor is a way to enforce implementation discipline. But a large part of it is mostly bling aimed at showing how strong (for an army) or smart (for an API) the people in charge are.

Case in point, APIs that have very simple requirements and yet make a big deal of the fact that they are perfectly RESTful.

Just today, I learned (via the ever-informative InfoQ) about the JBoss SteamCannon project (a PaaS wrapper for Java and Ruby apps that can deploy on different host infrastructures like EC2 and VirtualBox). The project looks very interesting, but the API doc made me shake my head.

The very first thing you read is three paragraphs telling you that the API is fully HATEOS (Hypermedia as the Engine of Application State) compliant (our URLs are opaque, you hear me, opaque!) and an invitation to go read Roy’s famous take-down of these other APIs that unduly call themselves RESTful even though they don’t give HATEOS any love.

So here I am, a developer trying to deploy my WAR file on SteamCannon and that’s the API document I find.

Instead of the REST finger-wagging, can I have a short overview of what functions your API offers? Or maybe an example of a request call and its response?

I don’t mean to pick on SteamCannon specifically, it just happens to be a new Cloud API that I discovered today (all the Cloud API out there also spend too much time telling you how RESTful they are and not enough time showing you how simple they are). But when an API document starts with a REST lesson and when PowerPoint-waving sales reps pitch “RESTful APIs” to executives you know this REST thing has gone way beyond anything related to “the fundamentals”.

We have a REST bubble on our hands.

Again, I am not criticizing REST itself. I am criticizing its religious and ostentatious application rather than its practical use based on actual requirements (this was my take on its practical aspects in the context of Cloud APIs).

14 Comments

Filed under API, Application Mgmt, Cloud Computing, Everything, JBoss, Mgmt integration, Protocols, REST, Utility computing

14 Responses to The REST bubble

  1. It’s always been a dangerous thing to use the R-word, and hyperbole to claim “compliance”, but that doesn’t diminish the value of building an API that is in essence just another Web site.

  2. Pingback: The REST bubble

  3. IF SteamCannon is trying to be RESTful, they’re failing. You’re not supposed to redirect the client like they’re doing based on failing authentication; I’m supposed to get the appropriate HTTP code, and *then* I should be on auto-pilot to the URI.

    How can you support HATEOAS, and not even implement it on the client end?

    Fail.

  4. Plus, where’s the state machine? You need one on the client; with all states pre-programmed before a URI request is made.

    I don’t see real HATEOAS.

  5. Well, you have to coax your customers into creating a browser! That’s going to take some convincing because writing a browser is hard — way harder than creating a web site, so a sales pitch is required.

    Really though, any API strategy that requires the customer to do the hard part is fundamentally broken.

    One alternate strategy (if you must be RESTful) is to produce a browser component that your customers can integrate with — think phantom.js here ( http://code.google.com/p/phantomjs/ ). Open source it; maybe your customer ecosystem (if one exists) will take it over from you. If your hypermedia format is widely adopted by your industry this is more likely.

    Another strategy is “Platform as a Browser” — make your infrastructure the browser and have your customers write web sites for it. This makes a ton of sense if your servers hold session state and are a source of events. This is how VoiceXML works: http://www.w3.org/Voice/Guide/

  6. Ho-Sheng Hsiao

    I’ve written a non-trivial RESTful API for a web service from scratch. There was no way to make it 100% compliant with HATEOS, though I’ve come close. We modeled ours after the Rackspace Cloud API. I have found marginal (but not significant) benefits in writing drivers to consume the RESTful-ish API.

    The real gain is in being able to add additional resources to the web service itself. That is, the discipline has better benefits for the me as the developer of the service than for me, as the consumer for the service. Because I can use runtime metaprogramming and the fact that REST-ish routes are orthogonal, it takes less than half an hour to add CRUD endpoints for a single resource to the code base, including a full test suite. Now, getting that resource to work with the business logic still requires the same level of effort.

    I think you’re right that advertising the RESTfulness of an API doesn’t point to any actual benefit. I will say I’d rather work with a RESTful API than with a SOAPy API, but Amazon’s API (or even say, Internetbs.net’s API) are acceptable. On the other side of the API, I can make a reasonable assumption that vendors providing a RESTful API may be able to iterate faster and have better internal engineering discipline.

  7. Haven’t looked at this specific API yet but between this post and the other one about Amazon potentially proving REST unnecessary I think, in the interests of fairness, it’s worth clarifying a couple of aspects of REST which seem to be causing confusion here:

    (It seemed a bit long for comments so I posted it on my blog instead)

    http://restafari.blogspot.com/2011/01/re-rest-bubble.html

  8. The bubble already burst with REST-*.

  9. The real benefit to adhering to the principles of REST is that you can build a web-scale service. Not just that your company’s service can scale to lots and lots of users—but that your service can scale to the whole web, even being implemented by and cooperating with all your competitors.

    That’s not always an attractive thing to a company, despite whether it’s actually a good thing in the long view or not. What is attractive, though, is to market the hell out of your purity vs whatever happens to be the buzzword of the day.

    If you’re designing an API for the web, what you really need to do is shut the hell up about how RESTfully-correct you are, and just DO it. Make an elegant API that serves your prospective developers—and hey if you can manage to establish a web-wide service and compete on the quality of your offering, so much the better.

  10. Pingback: Scott Banwart's Blog » Blog Archive » Distributed Weekly 87

  11. Pingback: This Week in #REST – Volume 32 (Jan 8 2011 – Jan 28 2011) « This week in REST

  12. REST in theory offers a way to build a web-scalable API which provides the least barrier to adoption by service consumers. Therefore if a vendor releases a REST API and makes use of REST in their marketing/sales pitch as a key differentiator, I find that reasonable. I would not call the REST phenomenon a bubble because of this. As time passes and REST becomes more widely used, we will see less of this.

    Please note: I do agree that we need a good way to document REST APIs (WSDL, WADL or WIKI Page – we need something). A service registry is a good central place to document such services along with other types of services.

  13. Stu

    REST advocates were born fighting for the style’s legitimacy for many years. Now it has legitimacy, but old habits die hard. Vendors have marketing dollars, online communities have snark. Both are ostentatious in their own way.

  14. There was a company called TraverseIT that was one of the first commercial implementors of REST to allow the creation and management of centralized Data Networks for complex web-based visualizations (I think they used Prefuse as their visualization platform). I learned from them that REST was a great API for getting data to a source and putting data to a target but it started to become difficult for more complex APIs. Like many of the other posters, I find that REST implementations are often weak in their documentation and most vendors overplay it.