Here's one of several 'lessons learned' that Werner recounts:
A second lesson is probably that by prohibiting direct database access by clients, you can make scaling and reliability improvements to your service state without involving your clients.
Interesting - since a database is also a service, what is the essential difference between direct 'database' access and direct 'service' access that improves the situation?
Another interesting comment:
Other lessons are related to how you access services: If you want to be able to aggregate services easily, if you want to insert advanced infrastructure techniques such as decentralized request routing or distributed request tracking, you need a single unified service-access mechanism.
Hmmm, the single unified access mechanism sounds like a protocol. I'm in the middle of building a new service and haven't been considering this - I wonder if I'm going to get in trouble. But I guess that's okay, since my business card does say Sr. Troublemaker...
Now this is the part that I like - as it involves my stuff!
About a million small and larger businesses sell on the Amazon platform. For example, if you go to one of the book pages, you will find that item is also available new or used from some of our many partners. These can be very small independent bookshops or larger retail operators that want to sell on our platform.
And onto REST...
Do we see that customers who develop applications using AWS care about REST or SOAP? Absolutely not! A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find. They are not interested in what goes on the wire or how request URLs get constructed; they just want to build their applications.