Preface

Building a good Application Program Interface (API) is essential for creating real-world applications that display data from a data source (most often a database). The job of the API, as you’ll see in this book, is the separation of concerns on a large scale; specifically separating the concerns of the frontend from the backend. This allows you to change one (e.g., swap out a new database) without breaking the other (e.g., a website) or vice versa.

A typical enterprise might have multiple teams working on the same overall product. For example, you might have a team working on a web presentation of your data, another working on the iOS version, and a third working on Android.

On the backend, you might have multiple data sources. In the simple example that we use in this book, we examine a car dealership. It might have input from sales, but also from inventory, from a service that provides information on average prices, and so forth. Some of this is static data easily stored in a database, some must be in a frequently updated cache, and some must be obtained on demand.

Coordinating the frontend with the backend is difficult and subject to catastrophic breakage should, for example, the format or calculations in the backend change. Furthermore, the needs of the presentation level are almost guaranteed to change over time. Finally, the frontend is most often not the ideal place to put your business logic.

APIs solve these problems. The frontend talks to well-defined endpoints, and the backend responds with well-defined data. What the backend does to get and manipulate that data is invisible to the frontend. For that matter, the uses that the frontend puts that data to are invisible to the backend. Most importantly, the API itself doesn’t need to know about either; it just knows what is being asked for and how to get it.