Hacker News Reader

Comment by quonn | Hacker News Reader

This article is very confused. It makes a case that an API is a boundary (which it is) and because there are also other boundaries (like borders) it must be a political boundary (which it is not). But it doesn't stop there. Once it has mistakenly _added_ the attribute "political" to boundary it goes on to essentially _drop_ "boundary", too. So now we are left with "political", so APIs must be about "power, money and respect" after all. Well, that's not my experience and this text does not provide a reasonable argument for this extraordinary claim. However I applaud the author for having tried to formulate a new concept that could have been interesting.

View on HN

I was excited to see a contrarian perspective here, but I'm disappointed that you've just selectively quoted the parent while claiming they are wrong. I would love to know how you define political and why you think the decision to make a function public instead of private is apolitical.

It's not apolitical. But it's also not necessarily political. Sure there can be different opinions about an API and some of those might have a political motivation (for a very broad definition of the word political). But this does not mean that APIs are primarily about politics. And there is certainly a huge leap to such concepts like power and money.

http://www.oxforddictionaries.com/us/definition/american_eng...

    The activities associated with the governance of a country
    or other area, especially the debate or conflict among
    individuals or parties having or hoping to achieve power.

Politics is not just about nation-states and the type of work usually associated with governments. Politics is what we call the various ways we humans solve our disagreements.

And yes, this can be about power and money, though political decisions come in all sizes.

internal politics are just about everywhere. at the office, at your favorite bowling league, at the fishing competition.

Apolitical: my opinion, which is natural and normal

Political: your opinion, which is biased and mindkilled

Go join any standardisation committee to see for yourself.

Well, that's about a standardisation process then. There are different parties involved, so of course there will also be some politics. But APIs are not limited to standardisation committees and politics certainly does not have the central role the article implies.

The point is that if there aren't multiple parties involved, it's not called API.

Ok, let's say I design and run a simple service that publishes stock market data and I expose the data using a REST API. If someone decides to use the service, you might argue there are multiple parties involved. But really, they are just using my service if they like it, otherwise they don't. There is not politics, power (I don't have any, except over a service I run on my own server) and money (The service is free) involved, if we want the terms to mean anything.

Sure, I get to make all the decisions, but if we now call every decision anyone ever takes political, the term looses all its meaning. Also note that those decisions are not limited to API at all: The implementation is just as political (e.g. availability, performance, privacy).

So it turns out that APIs and protocols (conflated in the article) and the implementation and - if it's a service - any other rule or practise affecting it can have political aspects, just like any other product or service or thing.

This is what I was thinking and I must have been thinking about it a lot longer before hitting the reply button because I believe I said almost the same thing. I just wanted to mention that I wouldn't have posted my reply if yours was here when I started composing it.

First answer this question: Why are you running the service? Respect? Trying to establish a lock in?

Then aswer the second question: Are you getting it? Do people respect you? Or do they ignore your service? Does the lock in happen?

No?

Then there's something wrong with the service. So let's have look at what our users want. Oh, it seems they have agendas of their own. So maybe if we tweaked the API a bit...

> Why are you running the service? Respect? Trying to establish a lock in?

Maybe I hacked it together on a rainy weekend.

> Maybe I hacked it together on a rainy weekend.

But why are you running it? What are your incentives? This is what I was writing about. Programmers, for some unknown reason, try very hard not to express their political interests and try to disguise them using technical lingo.

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.

> 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.

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...

> 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?

Reply on news.ycombinator.com