|
|
|
|
|
|
by akira2501
653 days ago
|
|
|
> You're at the mercy of the original database schema SQL has views. As long as you can represent the underlying data through a view you should be fine. > and may cause mistakes in interpretation in anything of scale All APIs have this concern. > direct access to a database is an unnecessary security risk You can constrain access to be read-only and to only access the particular view or views necessary. > has found putting up abstractions and interfaces to address those issues It could just be a crutch to avoid deep understanding of the underlying tools themselves. It's much easier to greenfield a new API. It's much easier to forget and accidentally abandon these APIs. |
|
|
This, and it doesn't have to be SQL, a number of other databases have similar concepts.
If you have a separate schema with views (in SQL terms), and the rest is either entirely walled off or available on a "you have been warned" basis, then this is simply an API with a clear contract, just a flexible one (not entirely unlike a GraphQL endpoint) and available over a less common (for APIs) protocol.
It can be risky for the API provider, though, unless it's a proper multi-tenant database. Given that those are less common, and, I guess, potentially harder to manage, it's probably why database access APIs are rare.