最近、私はRESTfulなAPIを設計しました。ヘッダーフィールドをLinkにしてHATEOASを実装したいと思います。HTTPヘッダーフィールドにCURIEを定義する標準的な方法はありますか？
これは問題なく動作しますが、APIのクライアントにとってより使いやすくしたいと考えています。例えば
Linkヘッダーは次のようになります。この場合
Link: <https://api.domain.com/orders/{id}>; rel="https://docs.domain.com/order"
は、クライアントがrel属性でhttps://docs.domain.com/order値を検索することによってリンクを見つける必要があります。
これはうまくいきますが、ドキュメントのURIが壊れやすく、長さがあるため、検索するキーとしては少し実用的ではありません。
だから私はそれの代わりにこのようなものにするためにCURIEを試してみて、使いたい：URIの変更の問題は大部分が緩和され、それははるかにコンパクトですされている方法
Link: <https://api.domain.com/orders/{id}>; rel="[rc:order]"
クライアントによる検索が容易になります。
私はLinkヘッダーフィールドを使用してHATEOASを実装しているので、レスポンス本文にメタデータを導入するのではなく、HTTPヘッダーフィールドとしてCURIEを含めることが最も一貫していると感じています。
API全体が標準のHTTPヘッダーフィールドとステータスコードをすべてのメタデータ（ページ番号、バージョン管理など）に使用するため、CURIEを定義するためにメタデータをレスポンス本体に導入しないでください。
しかし、HTTPヘッダーフィールドを使用する場合は、どのフィールドをCURIに使用する必要がありますか？
HTTPヘッダーフィールドでこれを行う標準的な方法はありますか？
そうでなければ、私はちょうどX-Curie: <https://docs.domain.com>; name="rc"のようなカスタムヘッダーフィールドを使用して、それをクライアントのためにどこかに書かなければなりませんか？
ほとんどのリソースはXMLまたはHAL標準を参照しているため、HTTPヘッダーフィールドに関するこれに関する情報は高く評価されます。
これが、RFCに必要なWebリンクです。それは述べている： "関係タイプを登録したくないアプリケーションは、関係タイプを一意に識別するURI [RFC3986]である拡張関係タイプを使用することができる"とそれは言う： "拡張関係タイプが比較されるとき、文字列（Curie [W3C.CR-curie-20090116]）のような別の形式でシリアル化されている場合はURIに変換した後に比較されます。 URIが必要でCURIEが許可されているので、私はCURIEを定義する標準的な方法があるかどうか疑問に思いました。 URIが間違いなく不安定であることを意味するわけではありませんが、CURIEが優れています。 –
少なくともそれはとにかくRFCの私の理解です。もちろん、私はCURIEを使用する必要はありません。HTTPヘッダーフィールドにCURIEを定義する標準的な方法があれば、クライアントにとってはより良いものになるはずです。 –
@ JakeLucas - あなたはその部分を誤解しています。 HTTPヘッダーフィールド以外の形式で表示されるリンク関係についてです。 –