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