5 ms·

I have to say I find this line of thinking somewhat incoherent. I'm thinking of cases where someone creates software and also offers an API to enable tooling, a

by h_r 11y ago

I have to say I find this line of thinking somewhat incoherent. I'm thinking of cases where someone creates software and also offers an API to enable tooling, alternative interfaces and that sort of thing. Take Github or Microsoft TFS, for example: they offer an API that exposes functionality that they control but what is political about it? Or say I offer a REST API at work to some business functionality locked up in a mainframe in order to expose it for reuse by other apps and workflows, and the consumers desperately want me to do it (or anyone who has the time to do so). What is political about that? Talking about the API is going to revolve around requirements that other apps have that could be satisfied by such an API. How is it useful to view that as a type of political border dispute? API seems to be a fairly narrow concept to me that appears in various contexts, some of them political and others not.

beagle3 11y ago
> they offer an API that exposes functionality that they control but what is political about it? Google's YouTube APIs played (and still does) a significant part in its turf wars against Microsoft. As did Google's MAPI support, and as did Microsoft's MAPI and SourceSafe APIs in the past (no longer in the MS world, so no idea about TFS). It's political. It's not "country governance" politics. But it is politics, in the give-and-take-between-opposing-forces sense of e.g. "Your WinPhone users don't get YouTube or Google Calenader because you keep harassing my Android partners". I agree with Sustrik that it's only considered an API (rather than an internal implementation detail) when multiple parties are negotiating.
- h_r 11y ago
  I'm curious what you call it when you add an API to some business functions that run on a mainframe in order to make them available to other external software written Java or .NET, for example. This kind of thing is done all the time in enterprise shops. Trying to frame it as a political power struggle between the negotiating parties frankly sounds pretty ridiculous. I have direct experience doing this sort of thing for years. It's really just a strategy for better leveraging your existing business assets. What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. If that context is missing (negotiating, somewhat hostile parties), then all you've done is say that you can't call it API. Hmmm ok then...
  - beagle3 11y ago
    > What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. Suppose it turns out that your MF RPC (or however your API is implemented) works too slowly, and instead of passing whatever through TCP, you are going to generate a file accessible through the shared MF/non-MF file system with the relevant contents. If all it takes is calling up Frank in the MF programming department to do the MF side (or even better, doing it yourself) -- then, no, it's not an API any more than your private class names and functions are an API - the MF/non-MF dividing line (which will likely also separate operating systems, programming languages, etc) is of no consequence, because there's no negotiation around changing it. I have witnessed exactly such a power struggle last time I worked in an environment that had mainframes (some 25 years ago) - functionality that was available on the MF was needed on a unix workstation. The amount of dev work on the unix side to do a mainframe RPC or to do it from scratch was comparable. From most perspectives, the unix re-implementation was a pure win. It sounds like a clear-cut decision, but the MF people argued fiercely against it -- to the best of my understanding, because they were constantly losing turf and relevance. Would you not call this political?

by h_r 11y ago

beagle3 11y ago

> they offer an API that exposes functionality that they control but what is political about it? Google's YouTube APIs played (and still does) a significant part in its turf wars against Microsoft. As did Google's MAPI support, and as did Microsoft's MAPI and SourceSafe APIs in the past (no longer in the MS world, so no idea about TFS). It's political. It's not "country governance" politics. But it is politics, in the give-and-take-between-opposing-forces sense of e.g. "Your WinPhone users don't get YouTube or Google Calenader because you keep harassing my Android partners". I agree with Sustrik that it's only considered an API (rather than an internal implementation detail) when multiple parties are negotiating.

h_r 11y ago
I'm curious what you call it when you add an API to some business functions that run on a mainframe in order to make them available to other external software written Java or .NET, for example. This kind of thing is done all the time in enterprise shops. Trying to frame it as a political power struggle between the negotiating parties frankly sounds pretty ridiculous. I have direct experience doing this sort of thing for years. It's really just a strategy for better leveraging your existing business assets. What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. If that context is missing (negotiating, somewhat hostile parties), then all you've done is say that you can't call it API. Hmmm ok then...
- beagle3 11y ago
  > What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. Suppose it turns out that your MF RPC (or however your API is implemented) works too slowly, and instead of passing whatever through TCP, you are going to generate a file accessible through the shared MF/non-MF file system with the relevant contents. If all it takes is calling up Frank in the MF programming department to do the MF side (or even better, doing it yourself) -- then, no, it's not an API any more than your private class names and functions are an API - the MF/non-MF dividing line (which will likely also separate operating systems, programming languages, etc) is of no consequence, because there's no negotiation around changing it. I have witnessed exactly such a power struggle last time I worked in an environment that had mainframes (some 25 years ago) - functionality that was available on the MF was needed on a unix workstation. The amount of dev work on the unix side to do a mainframe RPC or to do it from scratch was comparable. From most perspectives, the unix re-implementation was a pure win. It sounds like a clear-cut decision, but the MF people argued fiercely against it -- to the best of my understanding, because they were constantly losing turf and relevance. Would you not call this political?