3 ms·

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 b

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.

rjknight 11y ago
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.

rjknight 11y ago

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.