1

基本的な HATEOAS 原則に準拠した REST API があるとします。Itemsに属しUserます。

GET /item/13

{ 
  id: 13,
  name: 'someItem',
  type: 'someType',

  _links: [
    {
      rel: 'user',
      href: '/user/42'
    }
  ]        
}

ここで、特定のアイテムのユーザーを変更する方法が必要です。PUT または PATCH のいずれかを使用して、その変更を実行するのに適した方法はどれですか?

  1. 新しいリンクされたリソースの ID を JSON 本文の単純なプロパティとして設定することにより、新しい関係を確立します。

    PATCH /item/13
{
  userId: 43
}

  2. クライアントにリンク自体を入力として渡すことで、新しい関係を確立します

    PATCH /item/13
{
  _links: [
    rel: 'user',
    href: '/user/43'
  ]
}

私は通常、リンクを、GET 呼び出しから返される、他の形式 (他のリソースへの id:s など) で格納された関係の読み取り専用表現と考えています。POST/PUT/PATCH 呼び出しへの入力としてリンクを使用することは、私にはあまり自然なことではありません。また、リンクが配列であるという事実により、さらに奇妙になります (すべてのリンクを更新できるようにする必要がありますか? 1 つのリンクを更新できますか?)。しかし、さまざまな記事で提案されているのを見てきました。ベストプラクティスはありますか? リンクアプローチを使用する利点は何ですか?

4

1 に答える 1

4

REST のポイント (少なくとも 1 つ) は、標準インターフェースを介してすべてを可視化することです。言い換えれば、「関係」がモノである場合、それも独自のリソースを持つ必要があります。

API もより説明的である必要があります。これは主観的なものかもしれません。あなたのモデル/デザインの詳細をすべて把握しているわけではありませんが、「アイテム」には「リンク」がありません。「アイテム」は代わりに単一の「所有者」を持つ場合があります。この場合、次のようになります。

GET /item/123/owner

したがって、ユーザーの URL (または単純な表現) を POST または PUT すると、アイテムの所有者が「変更」されます。モデルで所有されていないアイテムが許可されているかどうかによっては、所有者の DELETE が許可されない場合があります。

この場合、「/item/123」の下の表現は「/item/123/owner」にリンクする必要があることに注意してください。これは、クライアントがサーバーから取得したリンクのみをたどるためです。

では、重要な「もの」とは何かを考えてみてください。それらすべてにリソースが必要です。また、できるだけ多くの「意味」/セマンティクスを追加してみてください。リレーションは「ユーザー」と呼ばれるべきではなく、「所有者」と呼ばれるべきです (または、モデルでの意味が何であれ)。

于 2016-01-26T10:02:09.633 に答える