| インターネットエンジニアリングタスクフォース | G. Luff、編集者 |
| インターネットドラフト | |
| intended status: 情報提供 | K. Zyp |
| 有効期限：2017年8月26日 | SitePen（米国） |
| G. Court | |
| 2013 |
JSONハイパースキーマ：JSONスキーマのハイパーテキスト定義
draft-luff-json-hyper-schema-00
JSONスキーマは、JSONデータの構造を定義するためのJSONベースのフォーマットです。このドキュメントでは、JSONスキーマのハイパーリンクおよびハイパーメディア関連のキーワードを規定します。
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に準拠して提出されています。
インターネットドラフトは、インターネットエンジニアリングタスクフォース（IETF）の作業文書です。他のグループもインターネットドラフトとして作業文書を配布する場合があることに注意してください。現在のインターネットドラフトのリストは、http://datatracker.ietf.org/drafts/current/にあります。
インターネットドラフトは、最大6か月間有効なドラフト文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。インターネットドラフトを参照資料として使用したり、「進行中の作業」として以外の方法で引用したりすることは不適切です。
このインターネットドラフトは、2017年8月26日に期限切れになります。
著作権（c）2013 IETF Trustおよび文書作成者として識別された人物。全著作権所有。
このドキュメントは、このドキュメントの公開日に有効なBCP 78およびIETF TrustのIETFドキュメントに関する法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントには、このドキュメントに関するあなたの権利と制限が記載されているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように、保証なしで提供されます。
JSONスキーマは、JSONデータの構造を定義するためのJSONベースのフォーマットです。このドキュメントでは、JSONスキーマのハイパーリンクおよびハイパーメディア関連のキーワードを規定します。
JSONハイパースキーマという用語は、これらのキーワードを使用するJSONスキーマを指すために使用されます。
この仕様では、JSONスキーマコア仕様 [json-schema-core]で定義されている用語を使用します。読者はこの仕様のコピーを持っていることをお勧めします。
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、RFC 2119 [RFC2119]に記載されているとおりに解釈されるものとします。
「スキーマ」、「インスタンス」、「プロパティ」、および「アイテム」という用語は、JSONスキーマコア仕様 [json-schema-core]で定義されているとおりに解釈されるものとします。
このドキュメントでは、JSONスキーマを使用してインスタンスデータにハイパーリンクを定義する方法について説明します。また、JSONデータをリッチマルチメディアドキュメントとして解釈するために必要な追加情報を提供する方法についても定義します。
コアJSONスキーマキーワードと同様に、「スキーマキーワード」セクションで説明されているすべてのキーワードはオプションです。
ハイパーリンクを定義し、「imgData」プロパティのマルチメディア解釈を提供するJSONスキーマの例を以下に示します。
{
"title": "Written Article",
"type": "object",
"properties": {
"id": {
"title": "Article Identifier",
"type": "number"
},
"title": {
"title": "Article Title",
"type": "string"
},
"authorId": {
"type": "integer"
},
"imgData": {
"title": "Article Illustration (small)",
"type": "string",
"media": {
"binaryEncoding": "base64",
"type": "image/png"
}
}
},
"required" : ["id", "title", "authorId"],
"links": [
{
"rel": "full",
"href": "{id}"
},
{
"rel": "author",
"href": "/user?id={authorId}"
}
]
}
このスキーマ例では、インスタンスのプロパティを定義しています。「imgData」プロパティについては、base64デコードして、結果のバイナリデータをPNG画像として扱う必要があることを指定しています。また、インスタンスのリンク関係を、インスタンスの値を組み込んだURIで定義しています。
上記のスキーマで記述されたJSONインスタンスの例は次のとおりです。
{
"id": 15,
"title": "Example data",
"authorId": 105,
"imgData": "iVBORw...kJggg=="
}
base-64データは、読みやすくするために省略されています。
このドキュメントの目的は、JSONデータをハイパーテキストとして理解できるようにするJSONスキーマのキーワードを定義することです。
JSONデータ自体をハイパーテキストとして解釈するには、クライアントからフォーマットに関する特別な知識が必要です。このドキュメントでは、予約キーワードを定義したり、JSONデータの構造を制限したりすることなく、そのようなJSONフォーマットのハイパーテキストおよびハイパーメディア解釈を記述する方法を提案します。
スキーマの「links」プロパティは、リンク記述オブジェクトをインスタンスに関連付けるために使用されます。このプロパティの値は配列でなければならず（MUST）、配列内のアイテムは以下に定義されているリンク記述オブジェクトでなければなりません（MUST）。
「links」キーワードを使用するスキーマの例は次のとおりです。
{
"title": "Schema defining links",
"links": [
{
"rel": "full",
"href": "{id}"
},
{
"rel": "parent",
"href": "{parent}"
}
]
}
単一のURIは、インスタンスに関連して複数の役割を持つ場合があります。これは問題ではありません。同じURIを複数のリンク記述オブジェクトで使用できます。
たとえば、このスキーマは、HTTPを介してアクセスされるブログ投稿のフォーマットを記述しています。リンクは、投稿のコメントにアクセスする方法、コメントを検索する方法、および新しいコメントを送信する方法をすべて同じURIで記述しています。
{
"title": "News post",
...
"links": [
{
"rel": "comments",
"href": "/{id}/comments"
},
{
"rel": "search",
"href": "/{id}/comments",
"schema": {
"type": "object",
"properties": {
"searchTerm": {
"type": "string"
},
"itemsPerPage": {
"type": "integer",
"minimum": 10,
"multipleOf": 10,
"default": 20
}
},
"required": ["searchTerm"]
}
},
{
"title": "Post a comment",
"rel": "create",
"href": "/{id}/comments",
"method": "POST",
"schema": {
"type": "object",
"properties": {
"message": {
"type": "string"
}
},
"required": ["message"]
}
}
]
}
クライアントが最初のリンクをたどると、URIは「/ 15 / comments」に展開される場合があります。2番目のリンクの場合、メソッドは「GET」（HTTPのデフォルト）であるため、このリンクをたどるクライアントはパラメータをURLに追加して、「/ 15 / comments？searchTerm = JSON＆itemsPerPage = 50」のようなものを生成します。3番目のリンクは、クライアントがURI（例：「/ 15 / comments」）にPOSTする可能性のあるインタラクションを定義します。ここで、ポストデータは新しいコメントのJSON表現です。たとえば、
{
"message": "This is an example comment"
}
JSONドキュメントをアドレス指定する場合、URIのフラグメント部分は、ドキュメント内の特定のインスタンスを参照するために使用できます。
このキーワードは、フラグメント部分に基づいてドキュメント内で適切なインスタンスを見つけるために使用する方法を示します。デフォルトのフラグメント解決プロトコルは、以下に定義されている「json-pointer」です。他のフラグメント解決プロトコルを使用してもよい（MAY）が、このドキュメントでは定義されていません。
インスタンスが「root」関係を持つリンクを提供するスキーマによって記述されている場合、またはそのようなリンクがHTTPリンクヘッダー [RFC5988]を使用して提供されている場合、「root」リンクのターゲットは、ドキュメント構造（「json-pointer」など）を使用するすべてのフラグメント解決メソッドの目的でドキュメントルートと見なす必要があります。 これの唯一の例外は、「root」リンク自体の解決です。
「json-pointer」フラグメント解決プロトコルは、JSONポインター [json-pointer]を使用して、インスタンス表現内のURIのフラグメント識別子を解決します。
「media」プロパティは、このインスタンスにJSON文字列でエンコードされたJSON以外のデータが含まれていることを示します。コンテンツのタイプとそのエンコード方法について説明します。
このプロパティの値はオブジェクトでなければならず（MUST）、文字列ではないインスタンスについては無視する必要があります（SHOULD）。
「media」キーワードの値には、次のプロパティのいずれかを含めることができます（MAY）。
インスタンス値が文字列の場合、このプロパティは、文字列をバイナリデータとして解釈し、このプロパティで指定されたエンコーディングを使用してデコードする必要があること（SHOULD）を定義します。 RFC 2045、セクション6.1 [RFC2045]には、このプロパティの可能な値がリストされています。
このプロパティの値は、RFC 2046 [RFC2046]で定義されているメディアタイプでなければなりません。このプロパティは、このスキーマが定義するインスタンスのメディアタイプを定義します。
「binaryEncoding」プロパティが設定されていないが、インスタンス値が文字列の場合、このプロパティの値はテキストドキュメントタイプを指定する必要があり（SHOULD）、文字セットはJSON文字列値がデコードされた文字セットである必要があります（SHOULD）（デフォルトはUnicodeです）。
「media」の使用例を示すスキーマの例を以下に示します。
{
"type": "string",
"media": {
"binaryEncoding": "base64",
"type": "image/png"
}
}
このスキーマで記述されたインスタンスは文字列である必要があり、その値はbase64でエンコードされたPNG画像として解釈できる必要があります。
別の例
{
"type": "string",
"media": {
"mediaType": "text/html"
}
}
このスキーマで記述されたインスタンスは、JSON文字列がデコードされた文字セット（デフォルトはUnicode）を使用してHTMLを含む文字列である必要があります。
値がブール値trueの場合、このキーワードはインスタンスプロパティを変更すべきではないこと（SHOULD NOT）を示し、ユーザーエージェントがこのプロパティの値を変更しようとすると、サーバーによって拒否されることが予想されます。
このキーワードの値はブール値でなければなりません（MUST）。デフォルト値はfalseです。
このプロパティは、検証のためにインスタンスのURIが開始する必要があるものを定義するURIです。"pathStart"プロパティの値は、JSON Schemaコア仕様 [json-schema-core]で定義されている最も近いURI解決スコープに対して、RFC 3986, セクション5 [RFC3986]のルールを使用して解決する必要があります。
インスタンスに対して複数のスキーマが参照されている場合、ユーザーエージェントは、インスタンスのURIが"pathStart"プロパティの値で始まるかどうかを判断することで、このスキーマが特定のインスタンスに適用可能かどうかを判断できます。インスタンスのURIがこのURIで始まらない場合、または別のスキーマがより長く、インスタンスにも一致する開始URIを指定している場合、このスキーマはインスタンスを記述するものと見なすべきではありません。"pathStart"プロパティを持たないスキーマは、それが参照されるすべてのインスタンスに適用可能と見なされるべきです。
リンク記述オブジェクト（LDO）は、単一のリンク関係を記述するために使用されます。スキーマのコンテキストでは、スキーマのインスタンスのリンク関係を定義し、インスタンス値によってパラメータ化できます。リンク記述オブジェクト（LDO）はオブジェクトでなければなりません。
リンク記述フォーマットはJSON Schemaなしで使用でき、このフォーマットの使用は、リンクを使用するデータ構造のスキーマとして、規範的なリンク記述スキーマを参照することで宣言できます。規範的なリンク記述スキーマのURIは、https://json-schema.dokyumento.jp/links（最新バージョン）またはhttps://json-schema.dokyumento.jp/draft-04/links（draft-04バージョン）です。
「フォーム」のような機能は、サーバーに提供するデータを記述するスキーマを提供する"schema"キーワードを使用して定義できます。
"href"リンク記述プロパティの値は、関連リソースのターゲットURIを決定するために使用されるテンプレートです。インスタンスプロパティの値は、RFC 3986 [RFC3986]に従ってURI参照として解決されるべきであり、URIへの相対参照であっても構いません。相対URI解決に使用されるベースURIは、インスタンスオブジェクト（スキーマではない）を取得するために使用されたURIであるべきです。
相対URI解決に使用されるベースURIは、次のように定義されます。
このプロパティは必須です。
"href"の値は、RFC 6570 [RFC6570]で定義されているように、URIテンプレートとして使用されます。ただし、いくつかの特別な考慮事項が適用されます。
URIテンプレート仕様 [RFC6570]は、変数名に使用できる文字セットを制限しています。ただし、JSONのプロパティ名は任意のUTF-8文字列にすることができます。
テンプレート内の任意のJSONプロパティ名の使用を許可するために、"href"の値をURIテンプレートとして使用する前に、次の前処理ルールを順番に適用する必要があります。
このステップの目的は、中括弧内の変数名をパーセントエンコードするためにブラケットの使用を許可することです。エスケープされる変数名は丸括弧で囲まれ、閉じ丸括弧文字 ")" は閉じ丸括弧のペア "))" としてエスケープされます。空の文字列はRFC 6570では有効な変数名ではないため、空のブラケットのペアは "%65mpty" に置き換えられます。
ルールは次のとおりです。
テキストの最大限に大きなセクションを次のように見つけます。
テキストのこれらの各セクション（周囲の丸括弧を含む）は、次のルールに従って置き換える必要があります。
上記の置換後、文字 "$"（ドル記号）が中括弧のペア内に出現する場合、テキスト "%73elf"（パーセントエンコードされた "s" を持つ "self"）に置き換える必要があります。
このステージの目的は、特別な値 "%73elf" によって、URIテンプレートでインスタンス値自体（オブジェクトプロパティまたは配列項目の代わりに）の使用を許可することです。
特殊ケース値 "%73elf" および "%65mpty" は、人間または自動エスケープによって誤って生成される可能性が低いため、選択されました。
たとえば、"href" のいくつかの可能な値と、前処理後の結果を次に示します。
{% raw %}
Input Output
-----------------------------------------
"no change" "no change"
"(no change)" "(no change)"
"{(escape space)}" "{escape%20space}"
"{(escape+plus)}" "{escape%2Bplus}"
"{(escape*asterisk)}" "{escape%2Aasterisk}"
"{(escape(bracket)}" "{escape%28bracket}"
"{(escape))bracket)}" "{escape%29bracket}"
"{(a))b)}" "{a%29b}
"{(a (b)))}" "{a%20%28b%29}
"{()}" "{%65mpty}
"{+$*}" "{+%73elf*}
"{+($)*}" "{+%24*}
{% endraw %}
最後の例では、"+" がブラケットの外側にあるため、エスケープされないままであることに注意してください。一方、4番目の例では "+" はエスケープされています。
前処理後、URIテンプレートはインスタンスからのデータを使用して埋められます。任意のオブジェクトプロパティ（空の文字列を含む）、配列インデックス、またはインスタンス値自体の使用を許可するために、次のルールが定義されています。
URIテンプレートの特定の変数名について、使用する値は次のように決定されます。
URIテンプレートによって参照される値がnull、ブール値、または数値の場合、最初に次のように文字列に変換する必要があります。
一部のソフトウェア環境では、数値の元のJSON表現は使用できません（1.0と1の違いを知る方法はありません）。そのため、妥当な表現を使用する必要があります。スキーマとAPIの作成者はこれを念頭に置いて、正確な表現が重要な場合は他のタイプ（文字列やブール値など）を使用する必要があります。
適切な値が使用できない場合があります。たとえば、テンプレートはオブジェクトプロパティの使用を指定していますが、インスタンスは配列または文字列です。
テンプレートに必要な値のいずれかがJSONインスタンスに存在しない場合、別のソース（デフォルト値など）から置換値を提供しても構いません。そうでない場合、リンク定義はインスタンスに適用されないものと見なされるべきです。
"rel"プロパティの値は、ターゲットリソースへの関係の名前を示します。このプロパティは必須です。
ターゲットへの関係は、オブジェクトを階層内に含むトップレベルリソースだけからではなく、スキーマ（またはサブスキーマ）が適用されるインスタンスオブジェクトから具体的に解釈されるべきです。トップレベルリソースからターゲットへのリンク関係は、トップレベルJSON表現を記述するスキーマで示される必要があります。
関係の定義はメディアタイプに依存すべきではなく、ユーザーは既存の承認された関係定義、既存の関係レジストリにあるものを含む（RFC 4287 [RFC4287]を参照）を利用することが推奨されます。ただし、JSON Schemaで定義された関係のコンテキスト内での規範的な解釈を明確にするために、これらの関係をここで定義します。
インスタンスからのデータによるパラメータ化が不要な場合、次の関係はスキーマ（関係の「from」リソースとしてのスキーマ）に適用できます。
たとえば、スキーマが次のように定義されている場合、
{
"links": [{
"rel": "self",
"href": "{id}"
}, {
"rel": "up",
"href": "{upId}"
}, {
"rel": "children",
"href": "?upId={id}"
}]
}
そして、インスタンスリソースのコレクションがJSON表現で取得された場合、
GET /Resource/
[{
"id": "thing",
"upId": "parent"
}, {
"id": "thing2",
"upId": "parent"
}]
これは、コレクションの最初の項目について、それ自身の（self）URIが "/Resource/thing" に解決され、最初の項目の "up" 関係が "/Resource/parent" のリソースに解決されるべきであることを示します。"children" コレクションは "/Resource/?upId=thing" にあります。
これらの関係値は大文字と小文字が区別されないことに注意してください。これは、HTMLおよびHTTPリンクヘッダー [RFC5988]での使用と一致しています。
関係 "root" を持つリンクが存在すると、ドキュメントのルートと見なされるものが変更されます。ドキュメント内をナビゲートするフラグメント解決メソッド（JSONポインターフラグメントなど）の場合、 "root" リンクのターゲットはそのようなメソッドの開始点である必要があります。
唯一の例外は "root" リンク自体です。関係 "root" を持つリンクのターゲットを計算する場合、既存の "root" リンクを考慮してはなりません。
たとえば、次のスキーマがあるとします。
{
"links": [{
"rel": "root",
"href": "#/myRootData"
}]
}
そして、URI： "http://example.com/data/12345" から返された次のデータです。
{
"myRootData": {
"title": "Document title"
},
"metaData": {
...
}
}
URI Data
-----------------------------------------------------------------------
http://example.com/data/12345 {"title": "Document title"}
http://example.com/data/12345#/title "Document title"
URL "http://example.com/data/12345" を正しく解決するには、 "root" リンクを考慮する必要があります。いくつかのサンプルURIと、それらが解決されるデータを次に示します。
リンク関係 "self" がオブジェクトの完全な表現を示すために使用される場合、ターゲットURIが "self" リンクを含むリソース表現を要求するために使用されたURIと同等ではないか、またはサブパスではない場合、ユーザーエージェントは表現をターゲットURIによって示されるリソースの信頼できる表現と見なすべきではありません。
たとえば、ハイパースキーマが次のように定義されている場合、
{
"links": [{
"rel": "self",
"href": "{id}"
}]
}
そして、リソースがsomesite.comからリクエストされた場合、
GET /foo/
応答は次のとおりです。
Content-Type: application/json; profile=/schema-for-this-data
[{
"id": "bar",
"name": "This representation can be safely treated \
as authoritative "
}, {
"id": "/baz",
"name": "This representation should not be treated as \
authoritative the user agent should make request the resource\
from '/baz' to ensure it has the authoritative representation"
}, {
"id": "http://othersite.com/something",
"name": "This representation\
should also not be treated as authoritative and the target\
resource representation should be retrieved for the\
authoritative representation"
}]
このプロパティはリンクのタイトルを定義します。値は文字列でなければなりません。
ユーザーエージェントは、ユーザーにリンクを表示する際に、このタイトルを使用しても構いません（MAY）。
このプロパティ値は助言的なものであり、リンクのターゲットがJSON表現を使用して返される場合、そのJSON表現の期待される構造を定義するスキーマです。
このプロパティは、"mediaType"と同様のセキュリティ上の懸念事項があります。クライアントは、リンクを辿った結果として受信したデータの解釈を支援するために、このプロパティの値を使用してはなりません（MUST NOT）。これは、「安全な」データの再解釈を許してしまう可能性があるためです。
例えば、2人のプログラマーがテキストのみのメッセージボードを使用してWebセキュリティについて議論しているとします。URIがhttp://forum.example.com/topics/152/comments/13である、その会話からのデータの一部を以下に示します。
{
"topicId": 152,
"commentId": 13,
"from": {
"name": "Jane",
"id": 5
},
"to": {
"name": "Jason",
"id": 8
},
"message": "It's easy, you just add some HTML like
this: <script>doSomethingEvil()</script>"
}
メッセージ文字列は、読みやすくするために2行に分割されています。
{
"rel": "evil-attack",
"href": "http://forum.example.com/topics/152/comments/13",
"targetSchema": {
"properties": {
"message": {
"description": "Re-interpret the message text as HTML",
"media": {
"type": "text/html"
}
}
}
}
}
第三者は、別の場所で以下のリンク記述オブジェクトを提供するかもしれません。
クライアントが上記のデータを解釈する際にこの"targetSchema"値を使用した場合、"message"の内容をHTMLとして表示する可能性があります。この時点で、メッセージに埋め込まれたJavaScriptが（"forum.example.com"ドメインのコンテキストで）実行される可能性があります。
このプロパティの値は助言的なものであり、このリソースを取得した際に返されることが期待されるメディアタイプRFC 2046 [RFC2046]を表します。このプロパティ値は、RFC 2161、セクション14.1 - HTTP "Accept"ヘッダー [RFC2616]で定義されているのと同じパターンを使用して、メディアレンジであっても構いません（MAY）。
このプロパティは、HTMLの<a>要素の"type"プロパティ（助言的なコンテンツタイプ）、またはHTTP Linkヘッダー [RFC5988]の"type"パラメータに類似しています。ユーザーエージェントは、リンクが辿られる前にユーザーに提示するインターフェースに情報を提供するために、この情報を使用しても構いません（MAY）が、結果のデータの解釈にこの情報を使用してはなりません（MUST NOT）。このリンクを辿って取得したデータを解釈する方法を決定する際、ユーザーエージェントの動作はこのプロパティの値に関係なく同一でなければなりません（MUST）。
このプロパティの値が指定され、リンクのターゲットがHTTP/1.1 "Accept"ヘッダーRFC 2616、セクション14.1 [RFC2616]をサポートするプロトコルを使用して取得される場合、ユーザーエージェントはサーバーにリクエストを行う際に、このヘッダーのアセンブリを支援するためにこのプロパティの値を使用しても構いません（MAY）。
このプロパティの値が指定されていない場合、値は"application/json"と見なされるべきです。
たとえば、スキーマが次のように定義されている場合、
{
"links": [{
"rel": "self",
"href": "/{id}/json"
}, {
"rel": "alternate",
"href": "/{id}/html",
"mediaType": "text/html"
}, {
"rel": "alternate",
"href": "/{id}/rss",
"mediaType": "application/rss+xml"
}, {
"rel": "icon",
"href": "{id}/icon",
"mediaType": "image/*"
}]
}
このスキーマで記述される適切なインスタンスは、4つのリンクが定義されます。"rel"値が"self"のリンクは、期待されるMIMEタイプが"application/json"（デフォルト）になります。"rel"値が"alternate"の2つのリンクは、現在のアイテムのHTMLバージョンとRSSバージョンの場所を指定します。"rel"値が"icon"のリンクは画像にリンクしますが、正確な形式は指定しません。
上記の例からのアイテムを表示するビジュアルユーザーエージェントは、RSSフィードを表すボタンを表示するかもしれません。このボタンを押すと、ターゲットURI（計算された"href"値）がニュースフィードアグリゲータータブなど、表示に適したビューに渡されます。
上記のやり方でリンクを表示したり、URIをニュースフィードアグリゲータービューに渡すことは、データの解釈ではなく、リンクの解釈を構成することに注意してください。データ自体の解釈はニュースフィードアグリゲーターによって実行され、メインビューに表示された場合にニュースフィードとして解釈されないデータは拒否されるべきです（SHOULD）。
リンク定義の"mediaType"プロパティは、リンクのターゲットの期待される形式を定義します。ただし、これは助言的なものであり、信頼できるものと見なしてはなりません（MUST NOT）。
データを解釈する方法を選択する際には、サーバーによって提供される（またはファイル名やその他の通常の方法から推測される）タイプ情報のみを考慮しなければならず（MUST）、リンクの"mediaType"プロパティを使用してはなりません（MUST NOT）。ユーザーエージェントは、リンクの表現方法や表示場所（たとえば、ホバーテキスト、新しいタブで開くなど）を決定するために、この情報を使用しても構いません（MAY）。ユーザーエージェントがリンクを外部プログラムに渡すことを決定した場合、最初にデータが通常その外部プログラムに渡されるタイプであることを確認するべきです（SHOULD）。
これは、"targetSchema"の予防策と同様に、「安全な」データの再解釈を防ぐためです。
以下のプロパティは、リンク記述オブジェクトにも適用され、HTMLフォームと同様の機能を提供し、サーバーに送信するための追加情報（多くの場合、ユーザーが提供）を送信する手段を提供します。
このプロパティは、ターゲットリソースへのアクセスに使用できるメソッドを定義します。HTTP環境では、これは"GET"または"POST"（またはその他のHTTPメソッド）である可能性があります。
一部のリンク関係値は、リンクに使用される適切なHTTPメソッドのセットを暗示しています。たとえば、クライアントは、関係が"edit"のリンクを"PUT" HTTPメソッドと組み合わせて使用できると想定するかもしれません。クライアントがどのメソッドが適切かわからない場合、これはデフォルトで"GET"になるべきです（SHOULD）。
存在する場合、このプロパティは、サーバーがターゲットリソースにあるインスタンスのコレクションのクエリまたは投稿をサポートするクエリメディアタイプ形式を示します。クエリは、ターゲットURIに追加して、サーバーから返されるべきリソース、またはリソースにデータを投稿するために使用されるリソース（メソッドに応じて）にプロパティベースの制約を付けてコレクションをクエリできます。
たとえば、次のスキーマを使用します。
{
"links": [{
"encType": "application/x-www-form-urlencoded",
"method": "GET",
"href": "/Product/",
"properties": {
"name": {
"description": "name of the product"
}
}
}]
}
これは、クライアントが特定の名前を持つインスタンスをサーバーに照会できることを示しています。
例えば
/Product/?name=Slinky
このプロパティには、送信されたリクエストの許容される構造を定義するスキーマが含まれています。GETリクエストの場合、このスキーマはクエリ文字列のプロパティを定義し、POSTリクエストの場合、これは本文を定義します。
これは、"href"のURIテンプレート（インスタンスからのデータを使用し、ユーザーによって送信されない）とは別であることに注意してください。また、クライアントがリンクを辿ったときに返されることが期待されるデータのスキーマを提供する"targetSchema"プロパティとも異なります。
このレジストリは、RFC 4287 [RFC4287]に従ってIANAによって管理されており、この仕様では"full"、"create"、"instances"、"root"の4つの値を追加します。新しい割り当ては、RFC 5226 [RFC5226]で概説されているように、IESGの承認を受けます。リクエストはIANAにメールで送信する必要があり、IANAはリクエストをIESGに転送して承認をリクエストします。
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1（ハイパーテキスト転送プロトコル -- HTTP/1.1）", RFC 2616, DOI 10.17487/RFC2616, June 1999. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs（RFCのIANAに関する考慮事項セクションの記述ガイドライン）", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008. |
| [RFC2046] | Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types（多目的インターネットメール拡張機能 (MIME) パート2: メディアタイプ）", RFC 2046, DOI 10.17487/RFC2046, November 1996. |
| [RFC5988] | Nottingham, M., "Web Linking（Webリンキング）", RFC 5988, DOI 10.17487/RFC5988, October 2010. |
| [W3C.REC-html401-19991224] | Raggett, D., Hors, A. and I. Jacobs, "HTML 4.01 Specification（HTML 4.01 仕様）", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999. |