4

リストの管理に使用する REST ストアを設計したいとします。リスト エントリは次のようになります。

<listentry>
    <position>0</position>                <!-- position in the list -->
    <data>interesting information</data>  <!-- entry data -->
</listentry>

次のようにリソースを設計します。

GET    /list/           // returns all list entries
GET    /list/{position} // returns the list entry at {position}
DELETE /list/{position} // delete list entry at {position}

PUT    /list/first      // update first list entry
PUT    /list/last       // update last list entry
PUT    /list/{position} // update entry at {position}

POST   /list/last       // inserts a new list entry at last position
POST   /list/first      // inserts a new list entry at first position

POST   /list/{position} // inserts a new list entry at {position} and moves all 
                        // entries down  the list starting from the entry that
                        // was at {position} before the insertion.

これは合法的な REST リソースですか? そうでない場合、リストを管理できるように残りのリソースを設計する方法はありますか?

編集

間違いなく役立つ情報をありがとうございます。first と last を特別な識別子として使用することは完全に合法であるという nategood と darrel に同意します (これに関する私の質問も参照してください)。もちろん、Saintdlama によって提案されているように、これらの魔法の識別子なしで行うこともできますが、これを行うと、今提示したい投稿リクエストでそれらを使用する可能性が失われます。

設計を再考しながら、リソース設計の提案に 2 つの機能を追加したいと考えています。

POST   /list/{position1}/swap/{position2}   // swap the position of two elements
POST   /list/{position1}/move/{position2}   // move the element at {position1} to
                                            // {position2} and move all entries 
                                            // down the list starting from the 
                                            // entry that was at {position2}

//possible uses
POST   /list/first/swap/last                // swap first with last element
POST   /list/42/swap/2                      // swap element 42 with element 2
POST   /list/first/move/42                  // move first element to position 42
// you get the idea ...

どう思いますか？

4

2 に答える 2

2

あなたのリソース設計は、私の REST の理解にはまったく問題ありません。単純なルールを導入して最初と最後のマジック インデックス機能を取り除くことで、デザインを改善できます。位置が指定されていない場合、最後のアイテムが更新されるか、アイテムが最後の位置に挿入されます。このルールを導入すると、first と last はもう必要ありません。最初はインデックス 0 を表すマジック文字列のみであり、最後は上記の規則により廃止されています。

@miku が述べたように、アイテムは独自のリソースになる可能性があります。1 つのリストで管理されるさまざまなリソース タイプが必要な、より一般的なリソース リスト デザインを計画する場合 (たとえば、リストはタスク、会議、予定を管理できます)、リスト アイテムはアイテム リソースへの参照 (リソース URL を使用) になる可能性があります。この参照アプローチを使用すると、リスト保持機能をリスト項目表現から完全に切り離すことができます。

編集：

この質問は、動くターゲットを取得しています:)

次のように、位置に関連するすべての操作をリソースとしてモデル化し、操作をサブリソースとしてモデル化できます。

POST   /list/positions/swap/0/2   // swap the position of two elements
POST   /list/positions/move/1/0   // move the element at 1 to 0

この位置リソースは、操作が成功したかどうかにかかわらず (HTTP) ステータスを返すことができます。移動、非同期のスワップ、戻りが必要な場合に操作のステータスを確認できる「操作」リソースへのハンドル (ロケーション ヘッダー経由)。すべてのリスト位置操作の何らかのログを提供するリソース。

ポジションをリソースとしてモデル化するというアイデアは、書籍RESTful Web Servicesから盗用されています。著者は、2 つの銀行口座間の送金トランザクションをリソースとしてモデル化しています。

于 2012-04-08T07:31:30.827 に答える
1

ほんの少しの考え：

  • .../first や .../last のような URL は一種の rpc っぽいものです

  • リスト項目はそれ自体のリソースのように見えるため、最終的には 1 つのリソースとして扱う必要があります。たとえば、次のようになります。

    GET /list/3/item/2

  • REST は簡単ではなく、ネストされたリソースなどに頭を悩ませるには時間がかかります。

于 2012-04-07T23:54:46.997 に答える