4 ms·
> 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. > an
by akira2501 2y 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.
- drdaeman 2y ago> SQL has views. 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.