2

私のモデルが次のとおりであるとします。

ユーザー:

  • ID
  • ニックネーム

私はコレクションを持っています/users/

より複雑なケースでは、「論理的な一意の制約」が存在しない可能性があるため、 User を では/users/{id}なくによって取得する必要があります。/users/${nickname}

したがって、使用できる基本的な JSON ペイロードは次のとおりです。

{
  id: 123,
  nickname: 'someUserName'
}

ここには派手なものはありません。


/users/ に投稿

私の知る限り、識別子としてのユーザー。これはリソース表現の一部であるため、ペイロード (?) に含まれている必要があります。

たとえば、DB シーケンスを使用して、バックエンドで自分で ID を生成したい場合はどうすればよいでしょうか?

次に、私のペイロードは次のようになります。

{
  nickname: 'someUserName'
}

これは適切ですか?

この POST の出力は何ですか? 何もない?IDを含むリソースの場所を参照するヘッダーだけですか?


/users/id で GET

リソースを取得したら、そのコンテンツを JSON として読み込みます。

{
  id: 123,
  nickname: 'someUserName'
}

/users/id に置く

私の知る限り、このメソッドで使用されるペイロードは、リソース コンテンツを「オーバーライド」することになっています。部分的な更新が必要な場合は、PATCH を使用します。

しかし、次のようにするとどうなりますか:

PUT /users/123

{
  id: 456,
  nickname: 'someUserName'
}

これは、リソースの ID を更新したいということですか?

URI とペイロードの両方で id を使用するのは冗長ではありませんか?


実際、私は を処理する方法をよく知りませんid

すべての POST / PUT / DELETE 操作で同じリソース表現を使用する必要があるかどうかはわかりません。

ID を一意の (?) リソース表現の一部にする必要があるかどうかはわかりません。しかし、ID が表現の一部ではない/users/場合、GET を使用してユーザーを一覧表示すると、ID が返されない場合、クライアントがユーザー ID を取得する方法がわかりません...

誰かが私を助けることができますか?:)

4

2 に答える 2

5

まず
HATEOASを使わないとRESTじゃない

これを理解していただければ幸いです。最後にもう一度説明します。

/users/ に投稿

POST ペイロードで ID を使用しなくても問題ありません。ID が存在する場合はエラー メッセージが表示されるため、開発者は自分のやり方が間違っていることを理解できます。
したがって、ユーザー リソースに他に何もない場合、ペイロードとしてのニックネームのみが完全に有効です。

サーバーの出力には、次の 3 つの重要な情報が含まれている必要があります。

  1. HEADER: 成功または失敗を示すステータス コード (通常は201 Created)
  2. HEADER: 新しく作成されたリソースの場所 (ちょうどLocation: /path/to/resource)
  3. BODY: 作成されたリソースの表現。GET のように完全なペイロードを返します。

得る

完全に有効

置く

PUT/PATCH に関する分析は仕様と一致します。新しいリソースはペイロードと同一である必要があり、ユーザーが異なる場合は ID を変更したいという意味です。ペイロードに変更してはならない値 (ID など) が含まれている場合、次の 2 つの可能性があります。

  1. ペイロードの ID を無視する
  2. エラーを返す

どちらの場合も、あなたが何をしたか、何が悪かったかをユーザーに知らせてください。400 Bad Request を送信/取得することを好みます。特権ユーザーが ID を変更できるが、特定のユーザーが 403 Forbidden を変更できない場合は、より適切な場合があります。また、API の動作を必ず文書化してください。API で ID を省略できる場合があります。POST ペイロードで指定された ID を一貫した方法で処理することを忘れないでください。

全体的な質問

REST はリソース上で動作します。
/users/ はリソースのコレクションの例です
/users/{id} は単一のリソースの例です
すべての応答で常にまったく同じ表現を使用する必要があります。何らかの理由で情報のスニペットのみを提供する方が適切な場合は、完全なリソース表現を指すメタデータ (リンク) を追加します。
ID は、ユーザーの最初の POST 要求を除いて常に存在します。POST は、リソースの将来の場所が不明であり、サーバーによって提供される必要があることを意味します。これは、GET /users/ が各リソースの ID を返す必要があることも意味します。

いつものように、API は厳密に戻り、要求を許容します。ユーザーが学習できるように、行動を文書化します。

ハテオアス

HATEOAS (Hypermedia As The Engine Of Application State) を実装すると、REST の真の美しさが明らかになります。これの一部は、有用なタグ/リンクの組み合わせで表現を糖化する必要があることを意味します。このようにして、クライアントは URL を作成する必要がなくなります。

ユーザー表現にHALを使用する例は次のようになります。

{
    "_links:" {
        "self": { "href": "http://yourrest/users/123" }
    },
    "id": "123"
    "nickname": "someUserName"
}

Matthew Weier O'Phinney が ZF2 REST モジュールを開発したときに、 HAL の使用に関するすばらしいまとめが彼のブログに書かれました(最初のエントリは完全に zf フリーで、HAL の説明のみです)。

于 2013-06-06T14:39:03.727 に答える
0

あなたの説明はid、 はリソースの一部ではなく、リソースの一意の識別子であると解釈しています。その場合、どの操作のペイロードにも含めないでください。

POST /usersペイロード{"nickname": "somebody"}を使用すると、Location ヘッダーで返される URL を使用して新しいリソースが作成されます。その URL はおそらく次のようになります/users/123が、クライアントの観点からは、それを期待する理由はありません。のように見えるかもしれません/something/else/entirely

GET /users/123(URL が以前の POST によって返されたと仮定して) は、ペイロードを返し{"nickname": "somebody"}ます。

PUT /users/123(上記と同じ仮定で)リソースを、PUTで​​送信するペイロードに置き換えます{"nickname": "somebody else"}

クライアントがリソースに名前を付けられるようにしたい場合は、PUT /users/123その URL で新しいリソースを作成することもできます。

リソースの名前を変更する一般的な RESTful な方法を私は知りません。クエリ部分または本文の一部として古い URL を使用した POST は理にかなっていると思います。

ここで、私が間違っていて、あなたがidリソース自体の一部になりたいと思っているとします。次に、すべてのペイロードにそれが含まれます。しかし、クライアントの観点からは"id": 123、URL が/users/123.

最後に、これはすべてかなり純粋な観点からのものです。URL をリソースの唯一の実際の識別子と考えることには価値がありますが、その規則を破って、クライアントにロジックを使用して URL を作成させることは悪いことではありません。

于 2013-06-06T14:48:28.223 に答える