If AWS sucked, or was merely a typical collection of services, then details about its API design might matter. Of course, AWS isn't typical – it's exceptional. Thus, its API could require the use of carrier pigeons and people would still be lining up to use it.
That said, nicer APIs are nicer. As someone that has programmed directly to EC2's APIs, I so wished they were less crufty. I now use jclouds (via pallet), so I thankfully don't have to think about such things anymore.
In addition, all the consumers get the benefit of a common specification - if you tell me your service is RESTful, I can probably start making requests without even knowing much more than a starting URI, because I know how GET, POST, PUT, and DELETE will behave; I know what the error/success codes are going to look like; I can guess that Content-Type is going to drive the input and Accept will drive the output.
Sure, the consumer is probably going to leap through whatever hoops I put out there if they want my data, but RESTfulness is a courtesy, extending a hand and saying I'm not going to make extra work for you.
In the case of the OP, I'd say "Amazon proves that people who want to use a well-designed and beneficial service will work with whatever they're given".
If you're launching a startup then you don't want to give your early adopters an excuse to not work with your API. If you're developing an API for internal use then you won't be using an off the shelf client library in any case.
Furthermore, a clean API is a sign to other developers that you know what you are doing. If you are targetting an industry where coders get a say on whether or not they will choose your service then you'd better put your best foot forward. I've seen far too many APIs that show a company has no clue on the technical side, which causes me to cast doubt on other parts of their service.
I'm involved in some API design again and I sent out a mail saying that any discussions involving whether option A or option B is the more 'rest-ful' thing to do will get smacked down :)
I think it's way more logical to POST a photo_id to http://flickr.com/galleries/123456/photos than to POST to http://www.flickr.com/services/rest/?method=flickr.galleries... (note: HN is truncating the displayed link.)
Then again, I don't think I'm in the target demographic for Azure.
But we work with other kinds of APIs as well, when a client asks. Apart having to do more work since we don't have code to reuse for that, we have no other problems.
If it works well, it does not matter if it's RESTful or not. But as for everything, if you are familiar with something, you are usually faster and more accurate.
I think whether you have REST or REST-like (i.e. RPC over HTTP) doesn't matter so much, as long as it's not SOAP.
That's what people are lauding.
Applying this to one of Vambenepe's examples of an AWS method--
"AWS mostly uses RPC over HTTP. You send HTTP GET requests, with instructions like ?Action=CreateKeyPair added in the URL..."
you can see that it's not RESTful. A RESTful version of this method would have something like "KeyPairs" in the URL path rather than in the query string, and it would use POST rather than GET to signify a create operation.
I think the best place to start from would be the Fielding dissertation: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch....
However, does it really make any practical difference whether the API makes full use of all the HTTP methods (GET, PUT, POST, DELETE)? Sure, it may be a bit of an abuse of the protocol to encode everything as a GET, but since you usually don't want any caching when using such an API, does it really matter?
In general, REST provides discoverability and interoperability that you don't get without a uniform interface.
If the API lets me get things done and/or provides an abstraction library in my language of choice so I never have to see it, I really couldn't care less how it is written.
Does REST make more semantic sense? Of course, but if your app has no features or consistently loses my data, I couldn't give a shit.
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.
"Every time a new API is announced, its 'nice-to-work-with-ness' is heralded as if it was a MUST HAVE feature. And yet..."
People work with what they have available to them. If another service came into existence that was in all respects the same as EC2, but had a nice, RESTful API, it would have an advantage.
Barring that, people use EC2.