Ive been pondering this one for a while and been meaning to put something out there about it.
During some of the architecture discussions I've had with colleagues some of the examples that are often put out there in terms of a public API are google and twitter. They are often described as things like "internet scale", "open standards based", "easy to use" and a whole bunch of other good things.
One of the things which I always feel that is a little bit ignored is that these companies are very different in terms of their market forces to some of the companies I have worked with in the past. If you are twitter for example its very easy to say this is my API and you will consume it using my rules. If twitter want to change their API or retire an older version of it then the client either upgrades or stops working.
If you are a service provider like one of these guys then you have all of the power and its really easy to produce an API and make everyone do it the way that suits you. I would describe this as a "provider driven API".
A lot of the companies I have worked with are different. They work with partners and customers who have a lot of power and the balance of power in their interactions and relationship is either finely balanced or in favour of the service consumer. In these cases we often end up with different scenarios where you may have an API, but you also end up having to build adapters or gateways to your API so that different consumers can work with it. To give an example of this we planned to produced an API but we found that one of our biggest consumers would account for 70% of its usage and they could only support a SOAP web service API with basic security where as another consumer of it would be REST based. In this scenario you may produce your "preferred API" and then produce adapters to convert different consumers to this API. The power balance means that you cant necessarily influence the consumer to change the way they would talk to your API because they would use a competitor who would make it easy and cheaper for them. Thats just the nature of business. In these cases I find that its important to try to use good integration practices and to keep the adapters as simple as possible and to reuse the core services in your preferred API. This will keep your total cost of ownership lower. I also often suggest to the business that they look for ways to incentivise partners to use our preferred API as this brings our costs down so we should look to share that saving for the longer term benefits it would bring. We know this isnt always possible though. In this case I would describe your API strategy as being a "consumer driven API".
I think its important to recognise that there are differences between these approaches, and that while google, facebook, twitter or Windows Azures's API might be excellent and very easy to use, they may be in a different business paradigm to your company and while there are definitely good techniques and practices to aim for they may not be the best comparison to your own situation.
This subject is not something I have really researched too much online to see if there is much in the way of discussion on this subject but im bored sitting waiting for a flight in miami airport and thought id get this one off my chest!
Id love to hear what other people think, is this a valid problem space that lots of us face, and what kind of challenges do you have in your domain. Also do you think the terms "Consumer driven API" and "Provider driven API" are right. Ive come across the "Client driven contracts" pattern but I feel that this is only part of the challenge.
From my own experiences the one good practice I would recommend in the "consumer driven API" space is that you should try to avoid developing whole new API's for all of the different consumers. Create your main API and then develop gateways to it. The gateways should be as simple as possible and do little more than mapping and composing the data from the main API into these newer formats and dealing with the differences in things like security. Dont go replicating all of the logic if possible.