サブストリストのリストからアイテムを更新/追加/削除するためのRESTデザイン

Question

サブリソースのリストを含むリソースを持っているときに、どの方法がベストプラクティスであるかを知りたいと思います。たとえば、名前、ID、誕生日、リストブックなどの情報を持つAuthorリソースがあります。この本のリストは著者との関係でのみ存在します。あなたは、あなたが本を削除したいリスト

から、本の名前を更新したい本のリスト

に新しい本を追加したい

1. ：だから、あなたは、次のシナリオを持っていますリスト

SOLUTION 1

は、私が正しい設計されている検索し、私は複数のアプローチを発見しました。私はこれを設計する標準的な方法があるかどうかを知りたい。追加するには

1. ：POST /authors/{authorId}/book/
2. を更新するには：PUT /authors/{authorId}/book/{bookId}
3. を削除するには：私はこの本によってデザインは以下のメソッドを持っていると言うと思いますDELETE /authors/{authorId}/book/{bookId}

SOLUTION 2

私の解決策は、書籍のリストがオブジェクト作成者の中だけに存在し、実際のものであるために、これらの3つのことすべてを行うPUTメソッドを1つしか持たないことです著者を更新する。ような何か：

PUT /authors/{authorId}/updateBookList（と著者のオブジェクトの内部全体を更新書籍リストを送信する）

私は私のシナリオでは、複数のエラーを見つけます。たとえば、クライアントからより多くのデータを送信し、クライアント上にいくつかのロジックを持ち、APIでさらに検証し、クライアントにBook Listの最新バージョンがあることに依拠します。

私の質問です：これを行うには反パターンですか？

状況1.私の状況では、私のAPIはデータベースではなく、別のAPIを使用しています。使用されているAPIには「updateBookList」というメソッドが1つしかないので、API内でこの動作を複製する方が簡単だと思います。それはまた正しいですか？

状況2.私のAPIがデータベースを使用するとしたら、解決1を使用する方が適切でしょうか？

また、いくつかの記事を提供できる場合は、似たような情報を見つけることができる書籍をご覧ください。私はこの種のデザインは石で書かれていないことを知っていますが、いくつかのガイドラインが役立ちます。 （例：REST API Design Rulebook）

Answer 1

私は最初のオプションを使用し、汎用ロジックPUTの中にすべてのロジックを詰め込む代わりに、別の方法を使用します。たとえデータベースではなくAPIに頼っているとしても、コードをあまりリファクタリングする必要はなく、いつでも切り替えることができるサードパーティの依存関係です。（パッチ標準を定義する）RFC 6902を見ると

から：一度に多数の書籍の更新を許可するつもりなら、その後、PATCHはあなたの友人かもしれないが、言われていること

クライアントの観点APIは、解決策2

PATCH /authors/{authorId}/book 
[ 
    { "op": "add", "path": "/ids", "value": [ "24", "27", "35" ]}, 
    { "op": "remove", "path": "/ids", "value": [ "20", "30" ]} 
] 

Answer 2

のように呼び出すことができ、非常に多くの方法がいくつかの処理を行い、その呼び出された古いスタイルのRPCのように聞こえます。 RESTの焦点はメソッドではなくリソースに重点を置くため、これはRESTの反パターンのようなものです。リソース上で実行できる操作は、基になるプロトコル（あなたの場合はHTTP）によって与えられます。したがって、RESTは基になるプロトコルのセマンティクスを遵守する必要があります。

さらに、RESTはURIの設定方法に気にしないため、実際にはRESTful URLはありません。自動化システムの場合、特定の構造に続くURIは、URIとして動作するランダムに生成された文字列と同じセマンティクスを持ちます。文字列に意味をなさないのは人間です。アプリケーションでは、URIにアプリケーションで使用できる論理名の種類を指定するrel属性を使用する必要があります。 URLの特定の論理的構成を予期しているアプリケーションは既にAPIに密接に結合されているため、RESTが解決しようとする原則、つまりサーバーAPIからのクライアントの分離を侵害します。

リソースをPUT経由でRESTfulな方法で更新（サブ）するには、基本的に受信したペイロードが、更新前の指定されたURIでアクセス可能なペイロードを置き換えるputのセマンティクスに従わなければなりません。

PUT方法は、ターゲット・リソースの状態が をを作成または要求メッセージペイロード内に封入表現 によって定義された状態でを交換することを要求します。

POSTリクエスト内のターゲットリソースがリソース自身のセマンティクスに従って 囲まれた表現を処理するために意図され、PUT要求内に封入表現に対し 状態を交換 として定義される

...ターゲットリソースのしたがって、PUT の目的は、義務であり、正確な エフェクトがオリジンサーバーにのみ知られているにもかかわらず、仲介者に見えます。部分更新に関して@Alexandruによって、またはペイロードは、サブリソースのコンテンツを置き換えるサブリソースに直接PUT要求を発行することによって示唆されるように部分的な更新がPATCHのいずれかを使用することにより可能であることRFC 7231状態で

ペイロードに1つを入れてください。サブリソースを含むリソースの場合、これは部分的な更新の影響を受けます。

部分コンテンツ更新は、（例えば、より大きなリソースの 部分に重なる状態で別々に識別されたリソースを標的 によって、または は、具体的に部分更新のために定義された別の方法を用いることにより可能です [RFC5789]で定義されたPATCHメソッド）。

は、あなたのケースでは、したがって、古いコレクションを置き換え .../author/{authorId}/booksリソースのようなものに PUT操作を経由して直接更新本のコレクションを送信することができます。これは多くの出版物を書いた著者のためにはうまく拡張できないかもしれないので、おそらく PATCHが望ましいでしょう。ただし、 PATCHには、アトミックおよびトランザクションの動作が必要です。すべてのアクションが成功するかどうか。アクションの途中でエラーが発生した場合は、すでに実行されているすべてのステップをロールバックする必要があります。

あなたのさらなる文学に対するあなたの要求に関しては、SOは、これに対して正確なトピック外のクローズ/フラッグの理由があるので、これを尋ねる適切な場所ではありません。