The Future of APIs: APIs aren’t the endgame they won't stay forever
1–10 of 63 posts
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#2There'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.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#3There'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 standar…
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.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#4This would be all good, if the goal was to have computers talk to other computers. In real life, typically organisations start talking to other organisations and _maybe_ there will be computers involved eventually. Most of the integration complexity is building a technical and functional clutch so two organisations can talk but do not leak too much (dynamic) complexity across their boundaries. And that does not lend itself well to automation.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#5There'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 standar…
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 n…
Great counterpoint.
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.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#6There's some very good info here towards the end, but the first half of the blog post made me wonder if they're going to get to it.
Perhaps this is just a function that it's a marketing post designed to simultaneously appeal to different audiences while explaining the problem to decision makers that are unfamiliar with what problem they're trying to solve. I sympathize, but as a designer acutely familiar with problems around API discovery, the first half was an extremely cringey read.
Anyway, you quoted all the right sources (save for Tim Berners-Lee's Semantic Web and Giant Global Graph), and I wish you much luck, but I think you're aware that this was tried before [1][2], where much less human interaction and intervention was required, and it nonetheless faltered. "Complexity" was a scapegoat at the time, and I think that's an unsatisfactory, almost too convenient of an answer, so how do you avoid that same fate?
[1] https://en.wikipedia.org/wiki/Web_Services_Discovery#Univers... [2] https://en.wikipedia.org/wiki/Web_Services_Description_Langu...
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#7Can we avoid replicating the tarpit that is WSDL for RESTful services? Time will tell, but I have my doubts.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#8This is my first time reading about JSON-LD, but it just sounds like a translation layer to map someone else's keys into my keys (or vice versa). Does this really get me a whole lot?
It seems like protocol buffers was made to solve a lot of the problems brought up here. GraphQL types and schemas seem to go a long way towards this as well.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#9There'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 standar…
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.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#10There's some very good info here towards the end, but the first half of the blog post made me wonder if they're going to get to it. Perhaps this is just a function that it's a marketing post designed to simultaneously appeal to different audiences while explaining the problem to decision makers that are unfamiliar with what problem they're trying to solve. I sympathize, but as a designer acutely familiar with problem…
Thanks for the review! I didn't mean the article as a marketing post, but I wanted to share my (long) thought process.
Nothing in the article is new in the concept, but maybe™ the time is now right. Frankly, what the part I'm concerned about isn't the semantics sharing at runtime, but it's the de-coupled, declarative approach in writing the clients.
With hypermedia, we've failed at the gates of client development. The devs tend to tight-couple their code with APIs, ignoring the consequences. If there won't be an incentive on client's side, then nothing from the article will matter.