The Future of APIs: APIs aren’t the endgame they won't stay forever
21–30 of 63 posts
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#22Here's the part I find most humorous. Machine to Machine communication has already been attempted, and it always fell back to requiring human intervention. Web Services Description Language (WSDL) was an attempt to exactly this, and it failed. WSDL didn't fail because it frequently tried to describe SOAP connectivity (and everyone knows that SOAP is obviously bad for all things), it failed because it was still people…
We haven't crossed that valley yet, mostly because we don't produce code that way either (flow instead of code). If we allowed that style of data flow, and a means of functional side-effect-free-validation waves hands vaguely, interop between different systems becomes an eventuality of the modeling.
The question is mostly... is the cpu-burn to detect the model that yields good results (ML-ish), cheaper than the human burn to write it on paper and agree. Present day we are ignoring the answer to that cost question for a variety of reasons...
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#23The fundamental difficulty with APIs is that they force clients and servers to use the same domain model. Humans are necessary because only humans have the intelligence to reconcile differences in domain models.
The idea of inventing some kind of discovery language is just deferring the difficult work of reconciliation. Computers will need to be as good at induction as the human brain before it will be possible to eliminate humans from the process.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#24There'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. Th…
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#25Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#26Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#27why is Google search lousy for API discovery? If I search for email sending Api, I get results for MailJet and SendGrid - relevant ones. If I search for entity identification api, I get AlchemyApi back - also relevant.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#28I think "using APIs" is AI-complete, thus making "autonomous APIs" a pipe dream until we have an AGI, and at that point APIs are not that interesting anymore.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#29The only prediction I have regarding autonomous API:s is: neuronstreams. If an API exposes a set of input channels and output channels where data can be sent between neural nets, they will be able to adapt to whatever format they see fit without having to make sense to us humans. It is a scary thought but if we want to remove humans in this process we shouldn't even be able to understand the communication.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#30There'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…
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.