Amazon proves that REST doesn’t matter for Cloud APIs

Every time a new Cloud API is announced, its “RESTfulness” is heralded as if it was a MUST HAVE feature. And yet, the most successful of all Cloud APIs, the AWS API set, is not RESTful.

We are far enough down the road by now to conclude that this isn’t a fluke. It proves that REST doesn’t matter, at least for Cloud management APIs (there are web-scale applications of an entirely different class for which it does). By “doesn’t matter”, I don’t mean that it’s a bad choice. Just that it is not significantly different from reasonable alternatives, like RPC.

AWS mostly uses RPC over HTTP. You send HTTP GET requests, with instructions like ?Action=CreateKeyPair added in the URL. Or DeleteKeyPair. Same for any other resource (volume, snapshot, security group…). Amazon doesn’t pretend it’s RESTful, they just call it “Query API” (except for the DevPay API, where they call it “REST-Query” for unclear reasons).

Has this lack of REStfulness stopped anyone from using it? Has it limited the scale of systems deployed on AWS? Does it limit the flexibility of the Cloud offering and somehow force people to consume more resources than they need? Has it made the Amazon Cloud less secure? Has it restricted the scope of platforms and languages from which the API can be invoked? Does it require more experienced engineers than competing solutions?

I don’t see any sign that the answer is “yes” to any of these questions. Considering the scale of the service, it would be a multi-million dollars blunder if indeed one of them had a positive answer.

Here’s a rule of thumb. If most invocations of your API come via libraries for object-oriented languages that more or less map each HTTP request to a method call, it probably doesn’t matter very much how RESTful your API is.

The Rackspace people are technically right when they point out the benefits of their API compared to Amazon’s. But it’s a rounding error compared to the innovation, pragmatism and frequency of iteration that distinguishes the services provided by Amazon. It’s the content that matters.

If you think it’s rich, for someone who wrote a series of post examining “REST in practice for IT and Cloud management” (part 1, part 2 and part 3), to now declare that REST doesn’t matter, well go back to these posts. I explicitly set them up as an effort to investigate whether (and in what way) it mattered and made it clear that my intuition was that actual RESTfulness didn’t matter as much as simplicity. The AWS API being an example of the latter without the former. As I wrote in my review of the Sun Cloud API, “it’s not REST that matters, it’s the rest”. One and a half years later, I think the case is closed.


Filed under Amazon, Application Mgmt, Cloud Computing, Everything, Implementation, Mgmt integration, REST, Specs, Utility computing

17 Responses to Amazon proves that REST doesn’t matter for Cloud APIs

  1. If it works, it works.

    That said, my personal experience is that the main benefit of REST comes in the development, rather than the use, of the API. Something about the mapping of resources to URIs and actions to HTTP methods has a flow-on effect to the internals of the API that results in a nice overall design. YRMV.

  2. Good post. The vast majority of AWS (or any cloud provider’s) users never see the API. They interact through language libraries or via web-based client apps. So, the only people who really care are RESTafarians, and library developers (like me).

    Perhaps it’s possible to have an API that’s so bad it prevents people from using it but the AWS Query API is no where near that bad. It’s fairly consistent and pretty easy to code to. It’s just not REST.

    It’s also worth noting that not all of AWS is in this boat. S3, CloudFront and Route53 API’s are much more RESTful.

  3. Lots of things succeed despite being inelegant, but that does not mean it’s not important to be elegant.

    Amazon can afford to have an inelegant API as they’re already dominant (and when they launched, they didn’t have many competitors).

    If someone launching an Amazon EC2 competitor today strapped together a pig-ugly set of RPCs over HTTP, I doubt it would encourage its use.

    Elegant APIs are a sign that you respect developers.

  4. Roger Menday

    What you say isn’t false to my mind, although the success of EC2 has very little to do with their API, as John (comment #3) points out too. More generally though I’m not sure I like the sound of all of this. Would the Web be here today if Tim Berners-Lee had designed an interface – specific to physicists – allowing them to share results once they had installed some specific “collaboration software for physicists” on their machines ?

  5. It seems strange that someone with such a clear idea of what a RESTful web service is for and why it’s there makes such a ridiculous statement as ‘… REST doesn’t matter for Cloud APIs’.

    At it’s simplest, REST is a way for communicating; a ruleset or a bunch of guidelines which, when adhered to, make being a consumer of these APIs much easier. I’ll address some points in the post:

    1) Your set of questions, all of which answer ‘No’, is missing one and a pretty fundamental one at that. Does the fact that AWS use their own implementation of an API instead of a standard like, oh, I don’t know, REST, frustrate developers who really don’t want to have to learn another method of communicating with AWS? Yes.

    2) The rule of thumb: Who writes these libraries for the Object Oriented Languages you speak of? Oh, yes – developers. See Point 1.

    3) If Rackspace are ‘technically’ right, then they’re right. There’s no grey area. Morally, they’re also right and mentally, physically and spiritually, they’re right.

    4) Yes, it is rich.

    As commenter John Leach says, it’s disrespectful to developers to implement and entirely different method of communicating with your API just because you’re amazon and you can do what you like.

    Put it this way. If, every time you hired a car, the cockpit setup was the same; the pedals were in the same place, the wheel turned left and right and the speedo was in front of you, you’re comfortable and happy. Then, one day, you hire a car from Amazon Car Hire. The pedals are now handles and they’re all identical, the wheel is a yoke and the speedo is above your head. You’d be pretty pissed off. Especially if Amazon Car Hire were the only people you could hire a car from.

    Not a perfect analogy, but the bottom line is, just because you’re amazon, doesn’t give you the right to buck the standard, regardless of how loose or ill-defined that standard might be.

    What happens when Microsoft do it? Everyone hates IE8 and there’s a furore.

  6. Pingback: In response to: Amazon proves that REST doesn’t matter for Cloud APIs « Mike Pearce – blog

  7. Exposing an API for a unique service offered by a single vendor is not going to get much benefit from being RESTful.

    Revisit the issue when you are trying to get a single client to work across a wide range of cloud APIs offered by different vendors; I’m willing to bet that REST would help a lot there. If this never happens — the industry decides that a custom client for each Cloud API is sufficient (e.g. not enough offerings on the market, or whatever), then REST may never be needed.

    But that is going to say more about the Cloud market/ecosystem than REST.

  8. Hello.
    Interesting post. I guess the flames around it are just passionated feelings about REST. Still, all your points are valid just because one simple fact: REST is not API technology.

    Let’s see. REST is for large distributed, hypermedia based, networked system. And it is an architectural style, not an API style or a Web Services generation technology.

    So, it is clear that if what you want is to manage, for a single vendor, sets of machines for a single client, REST features doesn’t seem critical. Actually, I totally agree that saying “this is RESTFul” is more a selling claim than an actual advantage.

    Actually, trying to tweak a solution to be RESTful just for the sake of having the right to put that in the title, is a non-sense.

    Now, you can have solutions that are REST based and exposed non-RESTful. And solutions that are at “unREST” and exposed using a “RESTFul API”. At the end, we cannot generalize about one style, as each solution may have different requirements.

    Maybe, let’s review the Cloud API requirement and then see if REST (or a subset) is needed.


  9. Tim Meaney

    …trying hard to follow the logic of your argument, which I’ll summarize as “RESTfulness doesn’t matter because Amazon is popular and doesn’t use REST” and “RESTful APIs don’t matter because libraries abstract away APIs anyway”. Both of these are flawed in logic – Amazon is popular because of the value it provides, not because of its RPC-style. Its popularity doesn’t signify that it’s architectural approach is preferred, or even sound. These are not synonymous.

    And saying that API style no longer matters because of libraries is awkward. What about developers or QA staff learning how to use an API? REST provides a universal vocabulary so developers and other technical staff don’t have to learn a new “language” each time they work with an API – that can’t be abstracted away in a library, as this is based on human understanding of the API.

  10. Pingback: Dec. 7: What We’re Reading About the Cloud: Cloud «

  11. If the product is good, like Amazon’s, these types of details don’t matter. If their API was horrible, it would be another matter and there would be a much bigger noise about it, but it’s not.

    There are plenty of intermediate libraries that are designed around RESTful concepts. REST itself is very straightforward from a resource-oriented viewpoint: do things sanely and consistently. It’s great to be able to use these to get started using APIs for awesome services very quickly. This is important for smaller services that need to prove themselves.

    Your questions are great but they totally miss the mark: these details (like RESTful APIs) primarily affect library developers, and good libraries can abstract away any kind of API into something more resource-oriented. That requires someone able to map concepts effectively and consistently. Once good libraries are available, there’s not a great barrier for adoption and excessive misuse and waste are completely coincidental.

    It always comes down to consistency: as long as you’re able to provide a consistent interface, even if it’s not consistent with previously established concepts and mappings, an API will likely succeed given the product is worth the (extra) effort.

  12. doesn’t RESTfulness impose some sort of security for your site in terms of hiding away the pages from the user. The user doesn’t know which page actually does all the processing. In this way I think security satisfied!

  13. Pingback: A mildly contrarian view of REST « On the ROA

  14. Pingback: William Vambenepe — Cloud APIs are like military parades

  15. Pingback: Amazon proves that REST doesn’t matter for Cloud APIs | Cloud Computing Software Development

  16. Pingback: 云API纷争又起:RPC还是REST | laura's site

  17. JW

    Betamax was a better technology, but “movers” of the industry adopted VHS and that was the end of it.

    Just because something is better doesn’t mean people will use it.