A while back I blogged that we need to learn lessons from the Salesforce.com web services API... the implication that I made was that they did it wrong. Since then, others have poked at it as well:
Recently I had to design some web service api's for various types of services. One client required a read/only ws api that proxied data from their database. In addition, they wanted all insert/update/delete to go through the business tier.
My design turned out interesting - for the WS proxy api to the database, it looked very close to the SF.com api.
For the ws api for the business services, it looked very much like Amazon:
Different services will require different invocation and granularity models. I think the SF.com got the api correct if you merely want to front-end a database. It is a bad design if you want to front-end business services. And the vice-versa is true with the Amazon way.
I'm going to try to be more careful when I blog service oriented designs... they are obviously context sensitive. One mistake that I see made is people saying that web services should be designed as 'course grained'. Well, you sure need course grained if you're going across a network with latency, but 'fine-grained' is just fine if you know that all your calls are In-Proc. Which, is an out-of-the-box function of the Microsoft WSE-2. My point is that we (bloggers) must be careful not to report 'generic' solutions without putting them in context - I'm as guilty as the next guy.