> Programmers are the exclusive consumers of the Application Programming Interface

That's the point. Programmers are the users of APIs. So build them for users, to support them in their work; don't build them programmers who need to hack around the API to get things done.

> while users don't have to know about it.

There is no difference between programmers and users. Everyone is a user, it's just a matter of perspective. If you creat an API you are the programmer, if you use an API you are the user. In both cases you have different knowledge, understanding and goals.

>It is true that "programmers are users, too" but this is like saying that tomato farmers also eat tomatoes; the farmer and the chef have different concerns.

It's not a good analogy because programming APIs are only used by the programmer. If this is an internal API then it's akin to the farming equipment that a tomato farmer might use to supply the chef with high quality tomatoes.

A farmer using high quality, efficient equipment will have an easier and more productive time farming tomatoes and therefore will have an easier time fulfilling the needs of chefs who want the tomatoes.

It's still very much a user interface. The users are your developers. I think people are confusing graphical user interfaces with user interfaces. A keyboard/mouse is a user interface into a PC.

If it's a public API then the API is your product. And it's very much a UI because that is the user interface, the users use your product in that way. That's why companies like Stripe are so loved by developers, they have a good API.

A farmer is not the one designing the farm equipment (though I respect how much they know and may be able to do maintenance on it). That's where this analogy breaks down. The original suggestion that APIs are less UX than UIs is based on the idea that developers make APIs and thus will easily understand other APIs, so that less investment in the experience is needed. Which is... nonsense? First of all, not all developers are API developers. Those in other disciplines will welcome the assistance provided by good design and documentation. Secondly, as much as I don't appreciate diving into someone else's spaghetti code, do I also not appreciate integrating with someone else's clunky API, even though I build APIs for a living.

>>>> this is like saying that tomato farmers also eat tomatoes

>>> it's akin to the farming equipment that a tomato farmer might use

>> A farmer is not the one designing the farm equipment

Great example of the problem of using analogies.

> someone else's spaghetti code

I'll not open this, erm, can of worms

An AP Interface, is the way for the programmer to act as the User of this Interface. It IS a user interface.

What should be taken seriously is proper domain and service modeling. The rest follows.

A good UI follows a good model. Visuals and trends are just a tiny bit.

There's a massive difference between a back button and gl.texParameterf().

I honestly have no idea what "proper domain and service modeling" means but a good UI is NOT a natural consequence of good engineering. That's why human interface design is a real discipline.

A back button is a GRAPHICAL User Interface.

Code/APIs are a different type of User Interface. Maybe we can call it PUI for Programmer User Interface.

No one said a back button isn't a user interface, the person you replied to just said that they were very different.

> Programmers are the exclusive consumers of the Application Programming Interface, while users don't have to know about it.

The term "user interface" is perhaps a bit unfortunate, and "human interface" would be better. In my usage of "user" here it's a synonym for "human".