|
|
| Service Oriented Enterprise |
|
|
Friday, August 22, 2003 Designing Web Service API's 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: CBDI Phil Windley 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. read( xyz) For the ws api for the business services, it looked very much like Amazon: AddEmployeeRequest( xyz) 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. posted by jeff | 9:46 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
