この記事は実装の例ではなく、コードがまったくないことをすぐに警告します。 それはむしろ、RESTのトピックを反映したものであり、私に知られているソースを集約しているので、私の問題に出くわした人たちも長い間行動のガイドを探す必要がありません。
この記事を書いた理由は、RESTエンティティの命名についての私の同僚との論争でした：彼はそれらを複数で呼び出すべきだと主張しました、例えば
books
ですが、私はそれが非論理的であると考え（そして今でも）、
book
選択肢を擁護しました。 2000年に作成者R. Fieldingによって書かれたRESTアーキテクチャの元のドキュメントを見つけるのではなく（最後にリンクを示します）、私たちは最初に自分の立場の論理的な正当性を発明し始め、その後、 、大企業で行われているように、いくつかの選択肢を整理して、彼らは鉱山がより一般的であることを確立し、その上で紛争を完了することにしました。
すべてはうまくいきますが、同じ議論が1か月後に別の同僚と繰り返されました。同僚は私が作成しているAPIのドキュメントを開き、私の命名方法に非常に驚きました。 以前に彼に与えられた議論を簡単に説明したので、リソースに適切な名前を付ける方法がわからなければ、これは永遠に繰り返されることに気付きました。
まず、両方のオプションを支持する主な引数を簡単にリストします。
単数の場合：
- これは「リソース識別子」ではなく「リソース識別子」です！
- アトラシアンはこれを持っています： docs.atlassian.com/atlassian-confluence/REST/latest-server
- モデルの説明に
books
エンティティはありません！
複数の場合：
- データベース内のテーブルは、複数形で呼び出される可能性が高いです！
- そして、このようにTwitterで： dev.twitter.com/overview/api/tweets
- www.restapitutorial.com/lessons/restfulresourcenaming.html
ご覧のように、議論は非常に物議をかもし、それぞれが100の反論を思い付くことができます。 それを誰かの実装に言及するために付け加えます。私は一般にそれをかなり無意味な活動だと思います。はい、アトラシアンとツイッターはITの巨人ですが、誰もが間違っている可能性があります。
RESTリソースのネーミングのさまざまなバリエーションを使用するリソースの膨大なリストをコンパイルすることに完全に消極的です。 代わりに、特定の命名規則のないフィールディングの論文を読みに行きました。 しかし、実際には議論の対象である「リソース識別子」の概念に関する明確な声明があります。 フィールディングが彼女について書いていることは次のとおりです。
RESTは、リソース識別子を使用して、コンポーネント間の相互作用に関係する特定のリソースを識別します。 RESTコネクターは、メンバーシップ関数の定義方法や要求を処理しているソフトウェアのタイプに関係なく、リソースの値セットにアクセスして操作するための汎用インターフェースを提供します。 リソースを参照できるようにするリソース識別子を割り当てたネーミング機関は、時間の経過とともにマッピングのセマンティック有効性を維持する責任があります（つまり、メンバーシップ関数が変更されないようにします）。
さて、つまり、フィールディングによれば、リソースへの識別子の割り当てに従事している特定の命名機関があり、それが名前の意味の正確さを担当するのはまさにそれです。 フィールディングは、この非常に意味の正確さに関するガイドラインを提供しませんでした。十分なロジックがあると信じていました。 さらに検索すると、同様の質問に対する彼のコメントを見つけることができます。これは、RESTの改良と標準化に対する彼の態度の本質を示しています。
「討論に費やされた膨大な時間」に関して、それは私の論文の目標に近い-望まれる特性と達成するために選択された制約に適用される実際の考えについての正直な討論を促進するソフトウェアアーキテクチャについての考え方を紹介するそれら（およびその結果生じるトレードオフ）。 情報が不十分であっても、ほとんど無駄になりません。
...
...せいぜい曖昧な概念を持つ委員会だけです
彼らが最も一般的でないものを書き留めるための設計と考えるものの
あらゆるマイクロソフトに基づく誤った情報の「ベストプラクティス」の分母
最後のリリースで実装することを選択しました。 IETFは、
最近。
つまり、完全に一般化すると、「自分で考え、自分で決定し、標準化すれば、ナンセンスで義務的なものになります」ということです。 まあ、一般的に言えば、この問題へのそのようなアプローチは、多くの異なる実装とアプローチの出現を引き起こすものの、遠慮のない標準と仕様を強制するよりもはるかに優れていますが、これは実際には「free-as-in-free-」の兆候ではありませんスピーチ»アーキテクチャ？
まとめると、リソースの命名という意味でRESTを実装するための間違ったアプローチはないように思えます。 ただし、次のことを考慮する必要があります。
- 元のREST記述では、「リソース識別子」の概念は、リソースを一意に識別する一意の識別子として説明されています。 ID、文字列表現のID、名前、ハッシュなどの識別子は指定されていません。この質問は、システムのライフサイクル全体を通じてアーキテクチャのセマンティックな整合性を維持するという唯一の条件を持つ開発者の裁量に任されています。
- アーキテクチャをユーザーが理解できるようにする必要があります。 データベース内のテーブルの名前やORMモデルの説明内のエンティティの名前などの内部実装機能は、背景にフェードする必要があり、理想的にはまったく考慮しないでください。
- 人気のあるリソースの実装を例にとると、間違いなく便利です。 しかし、将来、誰か他の人の認識に独断的に従うことは、何についての論争にもつながることを常に覚えておく価値があります。
ご清聴ありがとうございました！
ソース：