意図している答えになっているかどうか解りませんが、個人的な見解を書いておきます。
API はシステムに対する規格化 / 標準化した操作手段を提供することになるわけですが、API を準備する場合は、抽象的な概念レベルで『システムの在り方』や『構成要素とレイヤー』を把握し『外部へ提供する機能』を実現するために『必要な操作』を可能な限り明確化すべきです。ここが曖昧だと、似たようなモノや使いにくい機能が量産されることでしょう。
DB側のデータ操作などに対して API を構築するのは『システム内部の共通ライブラリ整備』という意味合いで、体系的な操作を準備することはよくあると思います。ただし、これは WebAPI ではない(このライブラリに対する wrapper を用意して WebAPI にするのはアリ)ですね。しかしながら、このレイヤーであれば DB自体の機能が使いやすいですし、サーバ間連携をしたいのであれば、API 関係なく DB上でデータ渡しをする構成で解決する方法なども考えられると思います。
WebAPI などの外部連携用インターフェイスの整備は一般的に AP(アプリケーション)側の話になると考えます。DB上に WebAPI を整備することは製品によっては(Oracle など HTTP に対する処理を実際 PL/SQL で15年以上前に私自身書いたことはあるので)技術的にできなくはないですが、今の時代に使うメリットはほぼ無いでしょう。
API がセキュリティ的に良いかどうかは設計次第です。例えば、必要だからといって DB に対して短絡的に書込操作ができる機能を提供した場合、認証や権限による制限などを併せて用意していなければ、外部から無制限に書込できてしまいます。これが許されるシステムの場合は問題ないわけですが、セキュリティ的に大きな穴だと判断されてしまうシステムもあるでしょう。また、データの取出など読取に関して際限なく引き出せると、通信などの負荷が全体的にかかるような事も考えられるため、場合によっては件数制限を加える必要があるかもしれません。このことから解るように、前提や設計が曖昧な状態で WebAPI を使っているから強固なシステムだ。などと単純に判断できるものでは無いと考えます。
WebAPI 自体は後から準備することも可能です。もし、外部のクライアントなり連携先システムとの同時開発が必要であれば、固定的なレスポンスなりを返す stub だけ用意して対処することも可能でしょうし、呼び出し側で工夫することも可能ですから、この辺は自分達にあった開発スキームを適用すれば良いでしょう。
あと、将来的な利用の想定だけして準備する。というのは余程の余力や経験、先見性がない限りしないほうが良いでしょう。実際の需要や必要な機能の差異は案外大きいものです。DB 操作用の WebAPI を準備したと仮定して、WebAPI は基本的に外部連携用のため、わざわざシステム内部から叩くと無駄な通信も発生しますからシステム自身で使うメリットもありません。整備するかどうかを判断する一つの指針として、明確な連携先と使い方/使われ方が想定できるかどうか?というのが使えるかもしれませんね。
以上、ご参考になれば幸いです。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。