10

2 つのリソース間の次の関係を検討してください。

  • 大学には多くの学部があります
  • 学部は大学に所属しています

明らかに、教員はここでは一流のリソースではありません。

次に、次の操作のためのエンドポイントが必要です。

  • この大学、このファームに新しい学部を作成します。2 つの操作でこれを行う 1 つの方法。
    • POST /faculties/
    • PUT /college/1/faculties
  • この大学から学部を削除します。再び2つの操作
    • GET /college/1/faculties:関連する学部のリスト。それぞれに のような自己 URL が含まれます/faculties/1
    • DELETE /college/1/faculties/1: URL は見栄えが良くなりますが、この URL を公開するにはどうすればよいですか?
  • その大学の下に 1 つ以上の学部を追加します。
    • PUT /college/1/facultiesこの大学の学部の完全なリストを受け入れます。
  • その特定のセクターを完全に削除します。
    • DELETE /sectors/1: 良さそうに見えますが、 のキャッシュを処理する必要があり/faculties/1/sectorsます。

この場合、より良いアプローチは何でしょうか?メンバーシップ リソースの公開について読んだことがありますが、そのアプローチでは、大学に 10 の学部がある場合、メンバーシップからすべての学部を取得するには 10 回の http 呼び出しが必要になります。

さらに、これは完全なリレーションシップ ツリーのほんの一部にすぎません。これをさらに拡張するために、システムが

  • 学部には多くの学科があります
  • 学科には研究室がたくさんあります。

さらに、RESTful アーキテクチャでは、クライアントが URL を設定することはありません。

なにか提案を?

4

1 に答える 1

5

私は過去に、OData がそのような側面をどのように実装するかについての投稿を書きました (「ナビゲーション プロパティ」機能)。次のリンクを参照してください: https://templth.wordpress.com/2014/12/08/updating-data-links-of-odata-v4-services-with-olingo/

この別のリンクも、末尾に URL と対応するペイロードが記述されているため、興味深いヒントが得られる可能性があります: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/ odata-v4/entity-relations-in-odata-v4 .

リクエストの数を最小限に抑えるために活用できる 2 つのケースがあると思います: 参照を操作するか、コンテンツを提供します。つまり、リソースが (コンテンツまたはカスタム ヘッダーに基づいて) 送信されたコンテンツを検出すると、参照 (添付ファイルのみ) またはコンテンツ (作成と添付ファイル) のみを処理する必要があるかどうかがわかります。

複数の基数 (大学 -> 学部) に対する次の可能な要求が表示されます。

  • POST /faculties/: 大学に所属していない学部を追加します
  • POST /college/1/faculties: 大学に学部を添付し、存在しない場合は最終的に作成します (送信されたコンテンツに基づく)
  • DELETE /college/1/faculties/?ref=/faculties/1学部を大学から切り離す

また、大学への参照を教員内に配置することも検討できます (要求POST /faculties)。そのため、作成中に要素をアタッチできます。

それ以外の場合、これPUT /college/1/facultiesは特定の大学に所属するすべての学部の表現全体を置き換えることを目的としています。

POST または PATCH メソッドを使用して、リクエストの数を最小限に抑えることもできます。詳細については、次の回答を参照してください: REST API - 単一の要求で一括作成または更新するおよびREST リソース コレクションを更新する方法。このようなアプローチにより、1 回の呼び出しで要素を作成し、それらをアタッチすることができます。要素の処理を収集できます。

私が明確であり、それがあなたの助けになることを願っています、ティエリー

于 2015-03-24T17:38:37.163 に答える