Not familiar with thrift or protobuf, but when I think of a single API layer in front of a database, the API specification becomes independent of the database.

Not familiar with thrift or protobuf, but when I think of a single API layer in front of a database, the API specification becomes independent of the database. You also want to version your API. Let's take an address for an example. Your contact database might have "id", "name", "addr_line_1", "addr_line_2, "addr_line_3", "city", "state", "zip". Your API v1 lets you query any combination of these fields and return a set of fields. /api/v1/contacts?zip=10018&fields=name [{"name": "Jessica Jones"}, {"name": "Matt Murdock"} ] /api/v1/contacts?name=Matt%20Murdock&fields=zip returns something like: [{"zip": 10018}] Later, you change your database to split name into fname and lname. You update your code and API to reflect this. In calls to /v1/ of the API, the field "name" is concatenated by your code to combine the database columns of fname and lname. In /v1.1/ of your code, you may or may not keep the "name" field as a convenience , but you do provide the ability to search on fname and/or lname fields. Basically, for any change to the underlying database, your API maintains the same interface to the data, however you might also publish a newer version of the API. In fact, your code that handles the API might be entirely different. For instance, /api/v1 might be handled by a python flask framework, while /api/v2 is handled by node. You can run multiple versions of the API at one time, supporting multiple iterations of clients. Obviously to reduce the amount of maintenance efforts, you will deprecate some versions and provide deadlines for them to be disabled. You can run all sorts of reports on the usage of each API endpoint and see what calls and response formats are still in use. This can open up the ability to do an outreach to those developing a client and make them aware of necessary changes.