Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of APIs: APIs aren’t the endgame they won't stay forever

blog.goodapi.co

Post reply on HN
Print view View original

31–40 of 63 posts

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#31

Post by zdne »

akytt wrote: post #4

This 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…

That's an excellent point! It's sure the case for the "building API to leverage (pardon me the word) the channels" scenario. These pre-agreed scenarios couldn't be automated. But other business drivers (direct data monetization or added value) would still benefit greatly from M2M approach.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#32

Post by sjayasinghe »

CodeWriter23 wrote: post #24
zdne wrote: post #10

Earlier quoted context omitted.

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…

I stopped reading at "Aliens". The Turk explanation was so patronizing IMO it reduced my tolerance for any other apparent nonsense not related to the topic at hand.

Do we really?

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#33

Post by zdne »

nathanaldensr wrote: post #23

Hold up an object in front of three people. Ask all three to describe the object and what it can do. You'll get three different answers. The 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 thing is, why APIs aren't a mix of domain vocabularies? Why the isolated silos with no interlinking?

The Web grew strong because sites were interlinked. REST APIs are supposed to be generalized Web and yet they are missing the links! What Went Wrong?

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#34

Post by devhead »

tomc1985 wrote: post #16
teilo wrote: post #7

Can 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 la…

on the client note...

code reuse is why these clients exist, if you are a developer I can promise you that you are not issuing tcp requests by hand and instead prefer to use some standard library (curl) to handle that for you.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#35

Post by mattmanser »

kogir wrote: post #18
tomc1985 wrote: post #17

Earlier quoted context omitted.

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 pub…

They were a bit of a nightmare. Fun highlights:

    - IsBooleanPropertyIncludedBoolean
    - Massive, incredibly slow to build libraries
    - Check everything in case it was null
    - Never really sure what was wrong when it went wrong
There was quite a massive cognitive overhead and overkill for often querying one little thing.

Also they'd sometimes break and you'd have to hand edit the wsdl's to get them to work again (at least salesforce used to break theirs every now and again, the wsdl would be incompatible with the .Net tool because of certain character not escaping properly).

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#36

Post by JCzynski »

I am extremely skeptical that autonomous APIs are possible without 90% of full natural language processing. Whatever we do to make APIs have their purposes be self-documenting, there will still be inferential gaps between what we say explicitly and what we mean.

We could adopt a highly rigid language describing what it is that an API provides and what purposes that data is useful for, but that's restrictive and very brittle, especially against Silicon Valley's favorite activity of disrupting established ways of doing things. Like going from proofs in ZFC to proofs in first-order logic, we can make it more stable but only at the cost of losing lots of power and expressiveness.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#37

Post by nathanaldensr »

zdne wrote: post #33
nathanaldensr wrote: post #23

Hold up an object in front of three people. Ask all three to describe the object and what it can do. You'll get three different answers. The 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 thing is, why APIs aren't a mix of domain vocabularies? Why the isolated silos with no interlinking? The Web grew strong because sites were interlinked. REST APIs are supposed to be generalized Web and yet they are missing the links! What Went Wrong?

The Web grew strong because of the combination of hypermedia and humans. When they look at a hypermedia document like HTML, humans can easily infer context, relevance, value, and a host of other hard-to-mathematically-define things.

I'm not sure REST APIs are supposed to be a generalized Web. In my view, REST APIs are simply a loose protocol on top of HTTP that allow computers running human-written code to communicate with one another. In general, there are several human-driven processes that must occur before REST APIs have any value. Example human involvement: Is this REST API valuable to my business? How much does this REST API cost to use? Does their domain model match ours enough to extract value from integrating with their REST API?

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#38

Post by JCzynski »

zdne wrote: post #33
nathanaldensr wrote: post #23

Hold up an object in front of three people. Ask all three to describe the object and what it can do. You'll get three different answers. The 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 thing is, why APIs aren't a mix of domain vocabularies? Why the isolated silos with no interlinking? The Web grew strong because sites were interlinked. REST APIs are supposed to be generalized Web and yet they are missing the links! What Went Wrong?

HTML pages are a sufficiently limited domain that integrating them is easy. More full-featured domains are progressively harder to integrate, scaling superlinearly with the possibilities added. (Probably exponentially.)

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#39

Post by mcphage »

I'm not sure this goal is very practical, even in the toy example you used (being able to swap data sources for weather forecasts).

If you can use a common vocabulary to access multiple APIs, that requires that all APIs implement the same feature set. Which means getting the API sources to agree on the features to implement, and how to describe them, and stop them from adding any features on that the others don't have. But of course, they'll all be motivated to add their own features, to distinguish themselves from their competition.

And once a API consumer is using a feature that other API producers don't support, then the consumer is locked into that producer, and the whole shared vocabulary is for naught. And of course the API consumers will be looking for additional features, because those translate into features that they can offer to their customers.

Basically, this requires API producers to work together to hobble their ability to meet their customers' needs, all to make it easier for their customers to drop them for a competing endpoint. So it looks like a net negative for everybody.

Re: The Future of APIs: APIs aren’t the endgame they won't stay forever

#40

Post by nso »

aargh_aargh wrote: post #2

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 standar…

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.

Post reply on HN