REST apiを設計し、できるだけRESTfulになるようにしています。組み込みたいのは [〜#〜] hateoas [〜#〜] です。 = json応答に。
関連するリソースにURLを追加するのは簡単ですが、それらのリンクに使用する構造についていくつかの議論がありました。
私が見つけた記事の多くは [〜#〜] atom [〜#〜] フィードから借りた構造を使用しています:
"links": [
{"rel": "self", "href":"http://example.org/entity/1"},
{"rel": "friends", "href":"http://example.org/entity/1/friends"}, ...
]
これはいくつかの質問を引き起こしました:
なぜ配列をコンテナとして使用するのですか?私が知っているJavaScript開発者によると、オブジェクトのプロパティとしてリンクを使用すると、リンクへのアクセスが簡単になります。例えば:
"self": { "href":"http://example.org/entity/1" }, /* (facebook uses this) */
"friends": { "href":"http://example.org/entity/1/friends", "type": "..."}
共通のjson構造はありますか(atomを再度適用する以外に)リソースプロパティでの参照?(たとえば、メッセージの送信者)。
参照はおそらくURLとして再度解決される必要がありますが、単純なIDを含めることも悪いでしょうか?のようなもの:
"sender": {
"id": 12345,
"href": "resource-uri"
}
私の考え方は、HATEOASはAPIを使用するためにクライアントが多くの知識を必要としないようにする一方で、その知識を使用する可能性を排除することに少し消極的です(リンクを作成してプロフィール画像にアクセスするなど)最初にユーザーを検索せずにクライアント側)。
私はAPI-Craftのgoogleグループでこのトピックを再開し、いくつかの素晴らしい回答を得ました。
アレイ設計の主な利点は次のとおりです。
原因のマップは、より良いアクセシビリティを持っています。
構造に関する限り、多くの可能性があります。
HALは最もクリーンなソリューションであるため、私はHALを使用すると思います。
構造に関する限り、HAL( http://stateless.co/hal_specification.html )またはJSON-LD:( http:// json-ld。 org / )
Httpメソッドに基づいて複数のリンクを提供できるようになると思います。
例えば.
"links": [
{"rel": "sender", "method":"post", "href":"http://example.org/entity/1"},
{"rel": "sender", "method":"put", "href":"http://example.org/entity/1"}, ...
]
多分あなたはそれをあなたの考えに合わせることができます
"sender": {
"href":"http://example.org/entity/1",
"methods": ["put","post"]
}