RESTful APIでリンク拡張のリレーションタイプのURIを指す必要はありますか？

Question

私は最近、RESTfulである必要があるAPIを設計しており、HTTPヘッダとクエリ文字列パラメータを排他的に使用するシステムを定義してメタデータを定義し、応答の本体が実際のリソースデータのみ。

しかし、私は今、HATEOASのリンクを考えています.HTTPヘッダーやクエリ文字列のパラメータをすべて保持したいので、HTTP Linkヘッダーフィールドを使用することに決めました。

これは、rel属性についての質問を提起しました。私は直接回答を見つけることができません。

私の考えは、リソースのコレクションのために応答して送信されますLink秒の1のようなものになるということです、これはRFC6570で定義されているクライアントは、単純な文字列の拡張を使用することができるようになるLink: <https://api.domain.com/things/{id}>; rel="..."

メタデータを各リソースに埋め込む必要がなく、クライアントがURIテンプレートとリソースID以外を知る必要がなく、コレクション内のリソースごとに正しいリソースURIを作成できます。

しかし、relがここにあるべきか、それとも何を指すべきかはわかりません。

URIは関係 タイプのセマンティクスの定義を含む リソースを指し示すことができますが、クライアントが必要です。

RFC5988で

、それは、拡張関係タイプはURIでなければならず、と言います がサーバーに負担をかけないように、そのリソースに自動的にアクセスしないでください。

私の質問は、RESTful APIではどのように定義されていますか？

私はちょうどrelのようなものをhttps://api.domain.com/media/thingのように作ることができます。

しかし、実際の定義内容はどのようなものでしょうか？

それは技術的には何かのように見えます。たとえば、簡単な説明のあるプレーンテキストのドキュメントです。

この種類のrel属性には、どのようなRESTful標準がありますか。

何か助けていただければ幸いです。

Answer 1

レベルRichardson's Maturity Modelを見ると、relは公開されたリンク/リレーションシップの名前を表しているようです。あなたのケースでは、curie:thing-by-id（たとえば、提案されたHAL draftで提案されているようにキュリーを使用している場合）に変換される可能性があります。考え方は、クライアントが実際のurlに耳を傾けずに、その名前（rel）でリンクを検索できるということです。