Comment by rjknight | Hacker News Reader

Comment by rjknight | Hacker News Reader

I'm puzzled by the pushback this is getting. There are many questions about APIs which are purely technical:

What does this API do? Can I invoke it using my preferred language? What performance characteristics does it have? Is it synchronous or asynchronous?

To that we can add questions about types, latency, protocols, and so on.

But there are plenty of non-technical questions: can I rely on this service to continue operating in the future? Can I be sued for using it, or for using it in certain ways? Can I build a commercial service using the API or the data it provides? If the API provides me with data that is incorrect, or illegal (containing copyrighted material, say), who is liable? What likelihood is there that the people running the service will degrade or shut down the service, demand increased payment for access to it, or offer preferential access to my competitors? Who owns, controls or distributes any data that I share via my invocations of the API? And what happens if or when the answers to any of these questions change, and how can I influence the direction of those changes?

Whether you call these 'political' questions or not is a matter of semantics. I think they're political in the sense that they're about the people running the service, rather than the technology itself. They're about who controls it, who decides the direction of its evolution, and what constraints they operate under. Those questions will depend on business, ethical, regulatory and philosophical considerations, and I don't think it's unreasonable to describe those as being 'political'.

Even many of your examples of "technical" questions seem at least partly political to me (which just reinforces your point, I think). For example:

* Language bindings: The decision to create and maintain an API binding in a particular language is mostly a political decision based on what your API consumers want. It is a trade-off between convenience for the consumer and extra work for the API developers. You will probably develop bindings for popular languages. But what if a language is very popular but also one that developers are unfamiliar with, so it would be a high cost to learn the language and develop the binding? Both the developer and the consumers are invested in the resulting decision, which makes it political.

* Performance characteristics: This can be political as well, because in a sense it's a negotiation between the developer and the consumer. How much extra work should the developer do to save the consumer some time? How much of the computation should be done "behind" the API, and how much should be pushed onto the API consumers?

* Protocols: Each protocol has costs and benefits for the API developers and for the consumers. For example Apple chose to expose their push notification service over TCP, not HTTP. This has costs for the consumers because now they have to use a 3rd party library to handle a new TCP protocol (or implement it themselves). On the other hand, Android's push notification service uses HTTP POST, which is more developer-friendly. I would argue this is a political decision (and a deliberate one on Google's part).

* Latency: Typically reducing latency costs the API maintainers more dollars, but it makes the consumers' applications more performant. This is also, in my eyes, a case of a political negotiation. How fast can we make it so that consumers are satisfied, while spending the least money? Or from the consumer's perspective, how much latency is "acceptable"? This embodies a political trade-off as well.

You could probably make similar arguments for almost every other API characteristic. The simple fact is that almost everything that involves multiple people with selfish interests is at least somewhat political.

I agree, although I think that some of those are less critical issues. For me, the reason to be aware of the politics around APIs is that APIs - unlike libraries - imply an ongoing relationship.

With a library, it is presumed (leaving aside the question of licensing, which is definitely political) that the decision about whether to use a library is purely technical: does it do the things we want it to do, with the correct level of performance, reliability and ease of use? You could imagine writing a test suite to determine definitive answers to these questions and, once answered, there would be no need to examine them again.

An API gives you access to someone else's product, and that product will evolve. Some of those evolutions may cause your product to break. If you're a Windows application developer, you can count on a pretty strong guarantee from Microsoft that they won't break Windows APIs, which is why programs from the 90s still run on modern versions of Windows, even if this requires some complex engineering from Microsoft. There was no technical aspect of the Win32 API circa 1995 that guaranteed these things; the commitment to future support was entirely political in nature.

The same applies to network-accessible APIs today. If your program achieves some result by invoking a statically-linked library, you can be certain that it will continue to work in the future purely on the basis of your technical knowledge. If you're relying on a third-party API, you cannot, and that's the distinction that the OP is asking us to take more seriously.

because your questions have nothing to do with the API itself.

It's like saying MS SQL is political because you have to ask whether or not you want to use it for a political purpose.

The purpose may be political, the tech is not.

Reply on news.ycombinator.com