I think M2M is great and all, but the thing is, the machines are doing something for the humans. We can tell a machine to go talk to another machine but neither machine will know WHAT they are supposed to do unless we tell them. The HOW is certainly something that can be solved with time and uniformity, but the WHAT is always something that will require a human presence. And ultimately, with all the humans in the world needing different WHATs, I don't see the required uniformity ever coming to be on any scale larger than the local central authority.
The Future of APIs: APIs aren’t the endgame they won't stay forever
11–20 of 63 posts
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#12I think M2M is great and all, but the thing is, the machines are doing something for the humans. We can tell a machine to go talk to another machine but neither machine will know WHAT they are supposed to do unless we tell them. The HOW is certainly something that can be solved with time and uniformity, but the WHAT is always something that will require a human presence. And ultimately, with all the humans in the wor…
The WHAT is provided by the users when they interact with some machine.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#13Unless somebody does it well, and it catches, we are going to repeat again and again reinventing UDDI, semantic web services and other past intents...
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#14This 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…
In real life, typically organisations start talking to other organisations and _maybe_ there will be computers involved eventually.
Do they? I work for a company that does a fair share of M2M integrations, yet we almost never talk to the other organization, we merely use their APIs. I don't know what's typical, but our case certainly isn't rare.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#15Here'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 writing the APIs and the descriptions of those APIs. And since people aren't perfect, humans had to intervene to find and fix the bugs to properly communicate with a WSDL defined API.
Until AI gets good enough, or we adopt a specific definition to meet all use cases (should be fun to watch), such attempts are going to keep failing. Because it's humans hiding in the box of the turk, and will be for the forseeable future, and computers are still pretty terrible at communicating with humans.
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#16Can we avoid replicating the tarpit that is WSDL for RESTful services? Time will tell, but I have my doubts.
Tarpit or no, WSDLs are pretty complete interface documentation.
It's still weird to me that people see APIs as a "thing", worthy of attention from business types and other nontechnical money-men, And how is it that a "good API" requires client modules for all these different languages? Do people not know how to make HTTP requests anymore or something?
(On the client note: "But it makes integration easier" or "I'm lazy, screw your docs, gimme [gems|pips|npms]" is the usual response I hear, though, given that each of these calls represents an external dependency requirement, maybe its good that they aren't as easy to use as the rest of your language?)
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#17Here'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…
The whole point of WSDL I thought was to look at statically-typed code and be able to dynamically generate the XML schema (and the XML) without human intervention -- that you can look at the code, know the types it uses and how it uses them, and then generate the WSDL based on that information?
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#18Here'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…
The whole point of WSDL I thought was to look at statically-typed code and be able to dynamically generate the XML schema (and the XML) without human intervention -- that you can look at the code, know the types it uses and how it uses them, and then generate the WSDL based on that information?
.NET and Java had good support for statically generating them (correctly even!) from code, but I never had the pleasure of integrating with such a service. Even in that case though, there were developers who used strings for everything instead of the correct types, didn't handle null correctly, etc.
Overwhelmingly in practice people wrote wsdls and xsds by hand, incorrectly, and treated them as secrets instead of publishing them along with the API endpoints. There was other "enterprise" BS during the XML craze too. In one case I even had to work around bugs in an IBM XML firewall, or its configuration. It was a nightmare[1].
Re: The Future of APIs: APIs aren’t the endgame they won't stay forever
#19The 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
#20Here'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…
"It's not enough for your computers to agree, you have to agree on what they're supposed to agree about."
Credit to Matt Levine: https://www.bloomberg.com/view/articles/2016-01-19/banks-oil...