web-dev-qa-db-ja.com

なぜ慣例では、DBテーブル名は単数であるがRESTfulなリソースは複数である必要があると言われているのですか？

データベーステーブル名は、少なくともSQLでは、単数形でなければならないというかなり確立された規則です。 SELECT * FROM user;この質問と議論 を参照してください。

RESTful APIリソース名が複数である必要があることも、かなり確立された規則です。 GET /users/123およびPOST /usersこれ を参照してください。

最も単純なデータベース対応のAPIでは、URL内のリソースの名前はテーブルであり、URL内のデータ要素と要求/応答本体は、DB内の列に直接マップされます。概念的には、この理論的なAPIによるデータの操作とSQLによる直接の操作の違いはわかりません。そのため、userとusersの命名規則の違いは私には意味がありません。

概念的にREST APIとSQLが同じことをしているときに、複数化の違いをどのように正当化できますか？

restapisqlconventionsnaming-standards
30
smitelli

REST spec（目的のレベルに関係なく）は、データベースアクセスとして設計されていません。APIアクセスに標準化をもたらすことを試みています。言及されているSQL規則（使用するかどうかにかかわらず） APIへのアクセスを考慮して設計されていません。SQLクエリを記述するためのものです。

したがって、ここで展開する問題は、APIがデータベースに直接マップするという概念的な理解です。これは少なくともアンチパターンとして記述されていることがわかります 2009年までさかのぼって 。

これが悪い主な理由は？ 「この操作がデータにどのように影響するか」を説明するコードクライアントコードになります。

これは、APIにかなりひどい影響を及ぼします。 （完全なリストではありません）

APIとの統合が難しい

次のように文書化された新しいユーザーを作成する手順を想像します。

  1. POST /users { .. }
  2. POST /usersettings { .. }といくつかのデフォルト値
  3. POST /confirmemails { .. }

しかし、ステップ2の失敗をどのように処理しますか？これと同じ処理ロジックが、APIの他のクライアントに何回コピーパスされますか？

多くの場合、これらのデータ操作は、クライアントから単一の操作として開始される一方で、サーバー側でのシーケンスが簡単です。例えば。 POST /newusersetup。 DBAはこれをストアドプロシージャとして認識しますが、API操作はデータベースだけでなく影響を与える場合があります。

APIの保護は絶望のブラックホールになる

2つのユーザーアカウントをマージする必要があるとします。

  1. GET /users/1
  2. PUT /users/2 { .. }
  3. DELETE /users/1

ユーザーの削除を許可せずにマージ機能を許可するユーザー権限をどのように設定しますか？ DELETE /users/1も存在する場合、/usersettingsでかなり代表されるユーザーを削除しますか？

API操作は、システムに複数の変更を引き起こす可能性のある（データベースよりも）レベルの高い操作と見なす必要があります。

メンテナンスが難しくなる

...クライアントはデータベース構造に依存しているためです。

このシナリオでの私の経験に基づいて：

  • 既存のテーブル/列の名前を変更したり削除したりすることはできません。それらがその機能のために誤って命名された場合や、もはや使用されていない場合でも。クライアントは壊れます。
  • 新しい機能は既存のデータ構造を変更できないため、既存の機能に全体的に属している場合でも、そのデータと機能は人工的に分離されることがよくあります。
  • コードベースは、断片化、紛らわしい名前、安全に削除できない残りの手荷物のために、徐々に理解が難しくなります。
  • ささいな変更以外はすべて、ますますリスクと時間がかかります。
  • システムが停滞し、最終的に交換されます。

データベース構造をクライアントに直接公開しないでください。特に、開発を制御できないクライアントです。 APIを使用して、クライアントを有効な操作だけに絞り込みます。

したがって、データベースへの直接のインターフェースとしてAPIを使用している場合は、複数化の心配はほとんどありません。使い捨て実験以外の場合は、APIが表す必要のある上位レベルの操作を決定するために、ある程度の時間を費やすことをお勧めします。そして、そのように見ると、複数形のAPIエンティティ名と単数形のSQLエンティティ名の間に競合はありません。彼らはさまざまな理由でそこにあります。

13
Kasey Speakman

REST APIとSQLは「同じことをしていない」

OPは尋ねます：

概念的に、REST AP​​IとSQLが同じことをしているときに、複数化の違いをどのように正当化できますか？

ああ、しかしグラスホッパーは、RESTfulインターフェースとSQLテーブルが「同じことをしている」と表示されるかもしれませんが、優れたプログラミングの衛生状態から、REST AP​​Iおよびデータベース。この点を無視することは、ソフトウェア啓蒙への道から外れることです！ :)

したがって、RESTful APIとSQLテーブルは、独自の慣用的な命名規則に従うことができます。これは、十分に文書化されており、他の場所で徹底的に議論されています。

5
fearless_fool