You've got to wrap the already basically-just-English SQL database in a layer of abstraction, then serve that as a proprietary API that's impossible to access without a precompiled library that targets a programming language you're not using and exposes methods that are 10x more difficult to use than a SELECT statement.
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.
My job consists of creating internal apis for databases to be consumed by internal systems. So yes, wrapping databases in APIs is very common and sometimes required.
The part I find weird of my job, is that the database isn't one of our team. We're accessing someone else's database, to be consumed by our own api, and writing a api to do so nicely. That's the crooked part.
There is no context in this world validating this level of unsanitized SQL. Even for internal use this is bad, since it bypasses the auth of server and dbms.
I was shortly in a project where the team and the customer meant the fucking Oracle DB when they were talking about "the backend".
There was Java Spring Boot (on some outdated, old old version), but all it did was pass args from a "REST" API (doing essentially RPCs with POSTs is REST, right?) to the DB.
The DB then had functions upon functions written in pl/sql that did the actual work.
I have no idea who the fuck thought that that was even remotely a good idea.
Anyways - I am happy to have moved on to better, more sensible projects :D