3

特定のリソースを「アクティブ」に指定できる REST API に取り組んでいます。説明するために、私が達成しようとしていることの簡単な例を次に示します。

書籍のコレクションを表す URI があるとします/books。

特定の書籍には、形式の正規 URI があり/books/{id}ます。

アクティブなブックへのポインターを提供する別の URI があります: /books/active. これは、アクティブな書籍の正規 URI を参照する HTTP 303 を送信するだけです。

クライアントがアクティブなブックを更新できるようにする最善の方法は何ですか? /books/activeアクティブなブックの正規 URI を指定する際にクライアントが PUT を発行できるようにする必要がありますか、またはこの種のことを行うための別の一般的に受け入れられているパターンはありますか? (クライアントが、リソースの実際の表現ではなく、正規の URI を送信する PUT を発行するのは奇妙に思えます。)

更新:一度にアクティブにできる本は 1 つだけです (相互に排他的)。したがって、アクティブ フラグを本自体のプロパティにすることは意味がないと思います。これは、複数の本が値を持つ可能性があることを意味するためです。 true に設定します。

4

2 に答える 2

2

のようなものを許可して URI に状態を組み込むのは悪い考えPUT /books/activeです。これは、適切なキャッシュを提供するサーバーの機能を完全に台無しにし、Tim Stokes によってアンチパターンとして指摘されています。

RESTful システムの URI は、リソースを一意に識別する必要があります。リソースの表現が変更される可能性があります (およびリソースの状態が変更される可能性があります) が、同じ URI を使用して別のリソースを指すことはできません。そうすることは、GET や PUT などのメソッドの予想されるセマンティクスに反します。

あなたの場合、books コレクションに単純にクエリ パラメータを含めることの何が問題なのですか? GET /books?state=activeたとえば、のようなもの。これにより、すべてのアクティブな書籍のコレクションが返されます (常に 1 冊の書籍である可能性がありますが、将来変更された場合はどうなるでしょうか?) そこからPUT正規の URI にドリルダウンできます。

さらに良いことに、リンク リレーション アーキテクチャを構築し、books コレクションの「self」リンクの隣に「active-book」のリレーションを単純に含めます。そうすれば、クライアントは URL 規則を意識する必要さえありません。サーバーが提供するリンクをたどるだけです。

于 2013-11-14T05:11:09.583 に答える