DBテーブル名は単数形であるがRESTfulリソースは複数形である必要があると慣習で規定されているのはなぜですか？

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

また、RESTful APIリソース名は複数にする必要があるという確立された規則です。GET /users/123そして、これをPOST /users見てください。

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

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

— smitelli
ソース

何もありません、単一の DBテーブルの命名も皆が続くことをRESTfulなリソースの命名における規則は。それどころか、多くの慣習があるかもしれません。衝突する可能性があるのは驚くことではありません。

— エリックキング

そのような確立された慣例はありません。私は常に複数のテーブル名を使用しています。 users、accountsなど、複数のものを保持しているためです。

— GrandmasterB

@GrandmasterB慣習は存在し、その関係はCoddのリレーショナルモデルに由来します。この関係モデルは、「関係」（テーブルは関係ではなく、関係になります）は単数の名前を持ちます。各関係は1つのリストです。関係はドメインエンティティをモデル化します。Coddのリレーショナルモデルでは、エンティティ名は単数形です。それが存在しないと言うことに関してそれについて豊富な文献があります。ただし、必要に応じて複数の名前を使用しても問題ありません。

— Tulainsコルドバ

@ user61852慣例によりそれを使用する人がいます。しかし、この質問で示されているように、キャメルケースやマークダウンがそうであるように、それは決して広く続いている業界の慣習ではありません。

— GrandmasterB

また、RESTはデータベースアクセスプロトコルではないことに注意してください。DB命名規則（これまでに使用したもの）とURL命名規則（これまでに使用したもの）が同じである必要はありません。それらは互いに無関係です。2つの非常に異なるドメイン。データベースが単一を使用し、URLが複数を使用する理由を熟考することは、データベースが単一を使用する理由を熟考するよりも意味がありませんが、システム管理者はファイルシステムディレクトリを複数と命名します。設計が不十分なWebフレームワークでは、RESTはDBアクセスと関係があると考える人がいますが、そうではありません。

— コーマックマルホール

回答:

REST仕様（どのレベルを使用する場合でも）は、データベースアクセスとして設計されていません。APIアクセスの標準化を試みています。前述のSQL規則（使用するかどうか）は、APIアクセスを考慮して設計されていません。SQLクエリを作成するためのものです。

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

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

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

APIとの統合が困難になる

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

POST /users { .. }
POST /usersettings { .. } いくつかのデフォルト値で
POST /confirmemails { .. }

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

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

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

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

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

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

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

メンテナンスが難しくなります

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

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

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

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

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

— ケイシー・スピークマン
ソース

別の質問に答えます。OPは、APIとDBエンティティの直接的な関連付けを意味するのではなく、両方のコンテキストにいくつかのエンティティが存在することを意味します。

— バシレフ

質問されていると思われる質問への回答をお気軽に投稿してください。

— ケイシースピークマン

@Basilevs実際、これは質問に答えていると思います。質問が誤った仮定に囲まれている場合、回答が間接的に表示されることがあります。「両方のコンテキストでのいくつかのエンティティの存在は、」彼らはいくつかのではなく他の人の間で1対1に対応することを意味同じエンティティ、ある意味します。複雑なデータモデルに対するAPIのこのような対応は、設計の欠陥を意味します。

— アルアンハダッド

これらには、Spring Data Restの使用をやめた多くの理由があります。

— Sebastiaan van den Broek

REST APIとSQLは「同じことをする」わけではありません

OPは尋ねます：

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

ああ、しかしグラスホッパーは、RESTfulインターフェースとSQLテーブルが「同じことをしている」ように見えるかもしれませんが、良いプログラミングの衛生状態は、REST APIとデータベースを仲介する中間層が常にあることを示しています。この点を無視することは、ソフトウェア啓発への道から外れることです！:)

したがって、RESTful APIおよびSQLテーブルは、独自の慣用的な命名規則に喜んで従うことができます。

— fearless_fool
ソース