>There is no rule stating that an API must be consumed client-side, and obviously a great many can't be

I wrote several responses to this but here's another one, if the server is serving rendered HTML to the client, how is that API-first development?

I'm not disputing the merits of this approach, I'm just wondering what we're arguing for here.

You develop a backend--a piece of software, running on your servers--with an API as its interface. Then you develop a frontend--another piece of software, running on your servers--that consumes that API, and has HTML as its interface. These are two separate projects.

We might be arguing about the meaning of words, but an API can be a lot of things. (I assume you know the things I'm about to say, and I don't mean any of it to come across as condescending--I'm legitimately trying to explain what people are arguing for when they talk about API-first development.)

All that an API needs to be (by definition) is a specification for how two pieces of software are meant to communicate. So yeah, technically the SQL interface to your database is an API--voila, API-first. But usually when people say API-first they are talking about an architecture that promotes reusability by considering that their web application might not be its only eventual consumer. That looks different depending on what you're building; if you're building Wikipedia "API-first" could mean that you're building a public API and then building a website around it (which you may still choose to render server-side for the reasons stated previously). If you're building an online game maybe "API-first" means you intend to have mobile clients consuming the API once you finish the web client. If you're building a business application, maybe "API first" is keeping your options open regarding future third-party integrations. In every case the controller logic has been encapsulated and there's an interface that could potentially be accessed by multiple consumers. (Specifically, in the case of a REST API it's an interface that can be accessed via HTTP, which is handy because then anything that speaks HTTP can communicate with your application.)

>how is that API-first development

We have several clients, the web site is one of the clients. The iOS app and the set-top-box are also clients. Figuring out the service boundary of your queries and events is part of the API development.

it's very possible to write code that can return responses in HTML or as JSON, XML etc depending on what the client asks for. Doing this allows you to concentrate on the API first but you can still add the presentation later.