Do you really? If you have permissions set up properly, it really seems like an API over a read-only SQL server is just an unnecessary layer of abstraction.
If your database is really big and suffers from large volumes of queries in a short time, it’s easier to implement rate limiting in the API than by configuring SQL server permissions.
It’s also easier to interact with stored procedures across multiple databases, from multiple clients, if you have a 1-to-1 API wrapper for your database procedures. This also lets you serialize your database response in a potentially more portable format than what your database returns directly, such as JSON.
The API wrapper isn’t a silver bullet for security and scalability, but it is a unified framework to configure better security policies and unify multiple databases.
I admit, however, that multiple layers of API abstraction is a bit of a meme, just to keep everyone on their toes.
Do you really? If you have permissions set up properly, it really seems like an API over a read-only SQL server is just an unnecessary layer of abstraction.
If your database is really big and suffers from large volumes of queries in a short time, it’s easier to implement rate limiting in the API than by configuring SQL server permissions.
It’s also easier to interact with stored procedures across multiple databases, from multiple clients, if you have a 1-to-1 API wrapper for your database procedures. This also lets you serialize your database response in a potentially more portable format than what your database returns directly, such as JSON.
The API wrapper isn’t a silver bullet for security and scalability, but it is a unified framework to configure better security policies and unify multiple databases.
I admit, however, that multiple layers of API abstraction is a bit of a meme, just to keep everyone on their toes.