There is no rule stating that an API must be consumed client-side, and obviously a great many can't be (depending on how auth is set up, etc). For projects where SEO matters but where an API will also be useful (or if you've just gotten into the habit of building user-facing bits around an API) you can render everything server-side, or first loads server-side and subsequent loads client-side. Airbnb's Rendr (https://github.com/airbnb/rendr) is neat for this, although there are a million other ways to do it.

If you combine this approach with something like CouchDB, your API can basically just be your DB interface and you can focus on building the user-facing bits.

EDIT: Sorry, everyone wrote the same thing at the same time :)

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.

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.

And if you go down that route, you pay for the increased deployment and maintenance complexity as well as the RTT to call the API service and consume the response as well as the CPU cost to render the page. There's no free lunch here. You can have both the API and rendering service on the same box, but now it's looking less and less clean and tidy, and more and more like a traditional web-app.

Your client (could be a web app consuming the api from the server) accesses the api like anyone else. You've created an api that others can build on - and you know that, because you're doing it yourself.

More to maintain. More cpu processing. Still a cleaner architecture though (compared to, say, having to maintain an external api for others to use while having a web app that talks directly to the db).