4 ms·
participants should send data that obeys the specifications, but they should be willing to accept data that doesn’t. This is what I believe to be the next lo
by doublerebel 13y ago
participants should send data that obeys the specifications, but
they should be willing to accept data that doesn’t.
This is what I believe to be the next logical step in device interoperability -- the "un-API". Inferring API-call intention from the provided data. It will require more than one datapoint and a feedback loop, but an API only has to be categorized correctly once -- rather than every implementation being created manually or relying on custom independent library. Zapier has touched the tip of the iceberg on this.
I am currently building a SaaS product to this end, please get in touch if this interests you.
- jmspring 13y agoThis is nothing more than the Robustness Principle - "Be conservative in what you do, be liberal in what you accept from others" http://en.wikipedia.org/wiki/Robustness_principle http://en.wikipedia.org/wiki/Robustness_principle
- doublerebel 13y agoYes, the article states that directly before the line I quoted -- I assumed it would be recognized. In practice very few APIs are tolerant of unexpected fields, values, or protocols. Forget the protocol war that other commenters are expecting, our devices should interact regardless of protocol. Only then will producers be forced to compete on useful features.
- ttflee 13y ago> Inferring API-call intention from the provided data Correct me if I was wrong. By 'Inferring', did you mean that a generalized broker/translator/proxy could be built in between of unlimited APIs, like the intermediate representation of a compiler?