49

JSON表現に基づいてRESTfulAPIを設計しています。HATEOASに準拠するために、私はリソース間のリンクを広範囲に使用しています。したがって、ATOMリンクと非常によく似た方法でリンクをシリアル化するために、この提案に従いました。

今、私は時々正しいリンク関係タイプを識別するのに問題があります。リソースにそれ自体へのリンクが含まれている場合、そのself関係は明らかです。リソースがサブリソースのコレクションおよび集約である場合、または関連リソースへの多くのリンクが含まれている場合は、より複雑になります。

例としてブログ投稿を取り上げ、ブログ投稿のスナップショットを返すリソースを考えてください。これには、このブログ投稿の作成者、タグ、コメントが含まれます。明らかに、このリソースには多くのサブリソースが含まれており、もちろんそれらへの個別のリンクも提供する必要があります。

サンプルリソース：

{
   "blogpost":{
      "link":{
         "rel":"self",
         "href":"http://blog/post/4711"
      },
      "author":{
         "name":"Bob",
         "link":{
            "rel":"???",
            "href":"http://author/uri"
         }
      },
      "title":"foobar",
      "content":"A long article here…",
      "comments":[
         {
            "comment":"great article",
            "link":{
               "rel":"???",
               "href":"http://blog/post/4711/comment/1"
            },
            "author":{
               "name":"John Doe",
               "link":{
                  "rel":"???",
                  "href":"http://author/uri"
               }
            }
         }
      ],
      "tags":[
         {
            "value":"foo",
            "link":{
               "rel":"???",
               "href":"http://blog/post/4711/tag/foo"
            }
         }
      ]
   }
}

では、特定のリンクに適切な関係は何ですか？のような関係タイプがあることは知っていますがtag、すべてのリソースが既存の関係タイプと一致するわけではありません。または、作成self者/タグ/コメントを参照するときに使用しても問題ありません。これは、JSON（サブ）オブジェクトを囲むコンテキストに関連しているためです。セマンティックエンティティselfは何を指しているのですか？

RFC5988は次のように述べています。

リンクのコンテキストは、表示される場所に応じて、フィードIRIまたはエントリIDのいずれかになります。

これをJSONの観点からどのように解釈できますか？それぞれの新しいオブジェクト{…}は新しいコンテキストですか？

ありがとう！

4

3 に答える 3

13

それは素晴らしい質問です。Halの例を見ると、rels がサブリソースのコンテキスト内で定義されていることがわかります。
rel がリソース全体または含まれるサブリソースにいつ関連するかについての決定的なガイドは知りません。
私が指摘できる唯一の追加情報は、フラグメントまたは完全に新しい URI を使用してコンテキスト IRI を再定義できる RFC5988 のアンカー パラメータです。

理想的には、メディアタイプは、ネストされたリソースに対してコンテキスト IRI が異なるかどうか、またはコンテキスト IRI を明示的に変更する必要があるかどうかを示す必要があります。これは、Hal 仕様が述べているように、単純な古い application/json の代わりに application/vnd.hal+json のようなメディア タイプを使用するもう 1 つの利点です。

@rel - ターゲット URI が「サブジェクト リソース」にどのように関連しているかを識別するため。Subject Resource は、最も近い親 Resource 要素です。

于 2011-08-09T20:05:54.177 に答える
-7

その質問に答えるのは少し遅いですが、将来の参考のために、これは私がこの問題を解決する方法です:

{
   "blogpost":{
      "title":"foobar",
      "content":"A long article here…",
      "link":{
         "rel":"self",
         "href":"http://blog/post/4711"
      },
      "link":{
         "rel": "author",
         "href": "http://author/uri",
         "alt":"Bob"
      },
      "link":{
        "rel": "comment",
        "alt": "great article",
        "href":"http://blog/post/4711/comment/1"
      },
      "link": {
        "rel":"tag",
        "href":"http://blog/post/4711/tag/foo",
        "alt":"foo"
      }
   }
}

考えてみると、コメント、タグなどはすべて、投稿にリンクされた個別のリソースです...それなら、それらをすべてそのままにしてみませんか..リンク！応答のサイズも節約できます ;)

于 2013-09-21T21:26:26.533 に答える