There's an economical problem with the proposed direction of development.
API providers are typically businesses or other actors whose interest is to lock the API clients nto their service. What would they gain by making their API interoperable with their competitors?
That is only viable for newcomers into the type of service and only works if they clone the API of an established player, not improve on it and standardize it.
Fair point! I'll try to answer with a question: So why is it that Google, Microsoft & Yahoo cooperate on schema.org to establish shared vocabulary?
They don't have to make it interoperable per se. It'd be enough to use some terms from a shared vocabulary (user, account, address) and then have some business-specific terms.
This way the business can use an existing library that knows how to handle user profiles. It's not that the full client has to be generic, a UI component that knows how to present a portion of a dictionary is enough.
> So why is it that Google, Microsoft & Yahoo cooperate on schema.org to establish shared vocabulary?
Reduced differentiation between underlying services drives them from product world into commodity world. Lower margins and stronger competition at that level certainly benefit the big players. Services in question, maybe not so much.
I guess the availability (technical possibility of building) of interoperable API does not mean that it will be used in every case. It would be used in cases where there is an economical benefit and vice versa.
I've built and contributed to APIs for companies on several occations. Every single time the thought behind it was to enable clients use the APIs with ease and to use existing standards, and not once was there any discussion regarding doing anything to "lock in" the clients to the service by making something non-standard.
I think most developers who has had the displeasure of doing integrations with third parties want to make that process as smooth as possible for whomever is to integrate with their system.
It depends on who the API is being built for. I've built a few APIs that were purely for business to business integration, and in those cases both sides want as little integration work as possible. Being able to dynamically generate a known good API client in that case is a big win.
API providers are typically businesses or other actors whose interest is to lock the API clients nto their service. What would they gain by making their API interoperable with their competitors?
That is only viable for newcomers into the type of service and only works if they clone the API of an established player, not improve on it and standardize it.