2012-04-07 16 views
4

リストを管理するために使用するRESTストアを設計したいとしましょう。リストを管理するためのRESTリソースを設計する

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リソースです:私はこのようなリソースを設計します

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

: リストエントリは次のようになりますか?そうでなければ、リストを管理できるように残りのリソースを設計する方法がありますか?

EDITは、それがdefinetly助け入力いただき、ありがとうございます。 私はnategoodとdarrelに、最初と最後の特殊な識別子の使用が完全に合法であることに同意します(これについてはquestionも参照してください)。もちろん、私はSaintedlamaによって提案されているような魔法の識別子なしでもやり遂げることができますが、私は今あなたに贈りたい投稿要求にそれらを使用する可能性を奪います。

デザインについてもう一度考えてみましょう。自分のリソース設計の提案に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 ... 

あなたはどう思いますか?

答えて

2

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

@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つの銀行口座間の振替取引をリソースとしてモデル化しています。

+0

リストに管理されているリソースへの参照を保存しますか? BTW最初と最後を削除するための回避策はありますが、特別な識別子の使用に関する編集を参照してください。 – Zounadire

+0

後半の編集については申し訳ありませんが、時にはアイディアが成長することもあります。私は、操作の状態を確認するためにハンドルを返すというのが理想的です。 – Zounadire

1

ちょうど少数の考え:... /第一または... /最後のような

  • URLはRPCっぽい
  • の一種であるリスト項目は、その資源のあると思われます

  • REST isn't easy

    GET /list/3/item/2 
    
  • 、それは nested resourcesなどを中心に自分の頭をラップするために時間がかかる:自身、それは最終的に1つ、例えばとして対処する必要がありそう。

+1

'/ first'と'/last'については "RPC-ish"とは何ですか? RESTfulなAPIのURIとしては問題ありません。これらのリソースには、同じリソースの標準URIを指し示す 'Location'ヘッダ(例えば' GET/first'のヘッダに 'Location:/ list/0'が返されます)があることを推奨します。 – nategood

+0

@nategood;私はRESTの専門家ではありません(私はまだFieldingの論文を読んでいます...) - ただし、URLはいくらか安定していなければなりません。おそらく頻繁に変わるでしょう。とにかく、RESTfulなもの/ firstと/ lastはうまくいくかもしれません。 – miku

+0

@miku最初と最後の概念は完全に安定しています。内容は変わるかもしれませんが、それは完全に正常です。 –

関連する問題