7

私はグーグルであらゆる場所を検索してみましたが、このトピックに関する決定的な権威を見つけることができませんでした. REST の原則に忠実でありながら、次の HTTP インターフェースをどのように設計すればよいでしょうか。

  1. 順序付きリスト (取得、追加、位置への挿入、並べ替え、削除)

  2. セット (取得、追加、削除)

  3. ハッシュ テーブル (取得、追加、削除)

注: これらのデータ構造には、既知の ID を持つ既存のリソースへの参照が含まれます。

4

5 に答える 5

10

それが、順序付きリストとハッシュ テーブルに対して行う方法です。セットとリストのメソッドは同じだと思います。

順序付きリスト

アイテム 123 を取得します。

GET /list/123

リストにアイテムを追加します。

POST /list/

新しい項目を位置 5 に挿入します。

POST /list/?position=5

アイテム 123 を位置 3 に移動します。

PUT /list/123?position=3

アイテム 123 を削除します。

DELETE /list/123

位置 3 のアイテムを削除:

DELETE /list/?position=3

もちろん、挿入と削除を行うときに、API はすべての要素のインデックスを更新する必要があります。

ハッシュ表

アイテム「somekey」を取得:

GET /hashtable/somekey

項目「somekey」を追加:

POST /hashtable/somekey

アイテム「somekey」を削除します。

DELETE /hashtable/somekey
于 2012-06-11T08:13:39.657 に答える
2

@ダダズ

このようなインターフェイスを直接定義することはできません。

順序付きリスト (取得、追加、位置への挿入、並べ替え、削除)

「位置への挿入」と「並べ替え」を除外することで、「取得」、「追加」、「削除」を完全に実装できます。次に例を示します。

  • リソース /service/users を定義します
  • POST /service/users を使用して、新しいユーザーを「users」コレクションに追加できます
  • /service/users を取得してユーザーを取得できます
  • /service/users/user-id を取得して、特定のユーザーを取得できます
  • ユーザー コレクションから /service/users/user-id を削除できます

これは非常に大まかな例ですが、いくつかのアイデアの概要を示しています。「並べ替え」と「位置への挿入」を実現するには、リソース表現に含めることができる独自のアクション セマンティクスを実装し、これらの操作を実行する方法をクライアントに知らせる必要があります。参考として、この JSON PATCH 仕様の提案を見ることができます: https://www.rfc-editor.org/rfc/rfc6902は、そのような操作を説明しようとしています。

既存のメディア フォーマットを使用する必要はありません。独自の名前空間で独自のメディア フォーマットを定義できます。

于 2012-06-11T08:13:59.020 に答える
1

基礎となるアプリケーションからトランスポート メカニズムを分離する必要があります。アプリケーションを正しく設計することを検討してから、HTTP 経由でアプリケーションにアクセスする方法を見つけます。このようにして、基盤となるアプリケーションに影響を与えることなく、トランスポート メカニズム (SOAP、SCA など) を簡単に追加または変更できます。

アプリケーションを正しく設計したら、アダプターやビジター パターンなどを介して HTTP リクエストからアクセスすることを検討してください。

于 2012-06-11T08:42:01.940 に答える
1

これが再注文の私の考えです。

リソースのフラグメントを更新するために使用される PATCH と呼ばれる HTTP メソッドがあります。リソースに という新しいプロパティを与えてindexから、PATCH メソッドで呼び出しを行います

PATCH /collection

[
  {
    "id: "original index 0"
    "index": 1
  }
  {
    "id: "original index 1"
    "index": 0
  }
]

次に、サーバーのバックエンドは、これをアトミックに行う方法を理解する必要があります。しかし、インターフェイスに関しては、これが RESTful に忠実であり続けるための最良の方法だと思います。

別の方法として、より良い解決策がありますが、すべてのケースに当てはまるとは限りません。順序付けは常に何らかの基準に依存するため、広告掲載順序と同じくらい単純な場合もあります。コレクションの URL がorderByクエリ文字列をサポートするようにし、これorderByによって結果の順序が決定されるようにします。次に、クライアントからの再注文呼び出し中に、注文基準に使用されるリソースのプロパティを更新するだけです。

于 2013-12-09T20:11:52.440 に答える
0

私は主に RESTful な並べ替え方法を探して、この質問にたどり着きました。私はどの回答もあまり好きではないので、これが最も RESTful だと思うものです。

再注文の場合、注文をリソースにすることができます。

/list/order

その後、通常の操作を行うことができます (これらの例では、現在 5 つの項目があるリストを想定しています)。

"items":" [
     {
         "id": "A",
         "name": "Monkey"
     },
     {
         "id": "B",
         "name": "Cow"
     },
     {
         "id": "C",
         "name": "Horse"
     },
     {
         "id": "D",
         "name": "Turkey"
     },
     {
         "id": "E",
         "name": "Tasmanian Devil"
     },
]

「注文」はリソース応答に含まれないことに注意してください。必要ありません。順序は、アイテムの応答順序によって暗黙的に指定されます。

GET /list/order

アイテム ID のリストを正しい順序で返します

['A','B','C','D','E']

POST /list/order ペイロード付き['D','B','C','A','E']

GET /list/order

アイテム ID のリストを正しい順序で返します

['D','B','C','A','E']

GETまた、 onを実行すると、リスト内のアイテムが正しい順序で返されることは明らかです/list。

GET /list

アイテムのリストを正しい順序で返します

"items":" [
     {
         "id": "D",
         "name": "Turkey"
     },
     {
         "id": "B",
         "name": "Cow"
     },
     {
         "id": "C",
         "name": "Horse"
     },
     {
         "id": "A",
         "name": "Monkey"
     },
     {
         "id": "E",
         "name": "Tasmanian Devil"
     },
]
于 2016-04-04T17:56:54.473 に答える