[305] HTTP における表現とは、 読み書きその他の処理の対象となるデータのことをいいます。
[8] RFC 7231 は、次のように説明しています >>6。
[7] 資源は何であっても良いとし、 HTTP が提供する一様なインターフェイスが独立した他者に対するメッセージのやり取りによってだけそれを観察したり作用したりできるような窓のようなものであると考えると、 やり取りにおいてそれの現在の状態や望む状態を表現する (代わりとなる) 抽象化が必要となります。この抽象化を、表現と呼びます REST。
HTTP においては、「表現」は、特定の資源の過去や現在の、あるいは望ましい状態を反映することを意図した情報であって、 プロトコルを通じて通信することができる形式にあるもので、 表現メタデータの集合と表現データの無限かもしれないストリームによって構成されるものです。
起源鯖は、対象資源の現在の状態を反映することを意図した複数の表現を提供されていたり、 生成することができたりします。そのような場合、 特定の要求に最も適切な、通常は内容折衝に基づく、 いずれかの表現を起源鯖が選択するアルゴリズムが用いられます。 この「選択された表現」は、条件付き要求の評価や
GETに対する200や304の応答の payload の構築でデータやメタデータとして使われます。
[34] HTML Standard は、 HTTP などいくつかの仕様書のいう表現が HTML Standard における資源である >>33 と定義しています。
[11] 表現の候補が1つ以上ある場合に、内容折衝などの条件によって選ばれた表現のことを特に選択された表現と呼んでいます。
[12] 「GET メソッドだったら返されるであろう表現」
のような呼ばれ方をしているものと同じと思われます。
[27] ただし「PUT メソッドが GET
メソッドで返される表現を置き換える」と言った場合に内容表現の影響をどう評価しているのかは、
これだけからは明らかではありません。
[28] WebDAV は「accept header なしの GET
で返される」といった言い方を使っています。
[2] 「選択された表現」は RFC 3229/RFC 3230 の実現値とほぼ同じ意味に見えますが、 明言されておらずはっきりしません。
[24] 実現値は、
その時点で指定された資源の選択された異体に対しての GET
要求への状態符号が 200 の応答で返されるであろう実体で、
0個以上の内容符号化の適用後であって、実現値操作や転送符号化の適用前のものをいいます >>22, >>26。
[13] 選択された表現は、応答メッセージに含まれるとは限りません。例えば
PUT では選択された表現が新たなものに変更されますが、
変更の前の表現も後の表現も応答メッセージに含まれるとは限りません。
[310] ところで要求メッセージの payload に含まれるデータのことや、
404 や 303 などの応答の payload
に含まれるデータのことも「表現」と呼ばれているようですが、
これらも定義上の表現の範囲に入っているのかはよくわかりません。
少なくても 200 で payload に含まれる“対象資源の”表現とは異なるものとして扱われているようですが...
[14] 対象資源の表現は、時を経て変更されることがあります。 ある時点での状態を指す時に現在の表現という言葉が使われます。
[307] 次のヘッダーは、表現メタデータ (表現ヘッダー) に分類されています >>306。
[308] メッセージに payload body が含まれるときは、 payload body に含まれる表現データの解釈方法を表します >>306。
[309] HEAD 要求に対する応答の時は、
GET だった場合の応答に含まれる表現データの解釈方法を表します
>>306。
[4] RFC 7232 は検証子のことを表現メタデータと呼んでいますが >>3, >>9、
検証子ヘッダーと >>307 は互いに素であり、両者の関係性は不明確です。
304 の規定においてはこの広い意味の表現メタデータが使われています。
[17] RFC 7233 は表現ヘッダー (representation header field) という用語を使っており >>16、意味的には >>4 と同じものを指していそうですが、真の意図は不明です。
Prefer: return=representation[19] Prefer: return=representation は、
成功した要求に対する応答は資源の現在の状態の表現とするべきことをクライアントが望んでいることを示します
>>18。
[29] Prefer: return=representation
に指定する引数として、次のものがあります。
[20] Prefer: return=representation が指定された場合、
応答の payload body は当該要求の処理の適用後の適用対象の資源の表現とすることが期待されています。
[21] その際、当該表現は実効要求URLの表現ではなく、他の資源の表現である場合もあります。その場合は返された表現の
URL を Content-Location: ヘッダーで指定できます >>18。
- representation
- An entity included with a response that is subject to content negotiation, as described in section 12. There may exist multiple representations associated with a particular response status.
The dictionary definition for "entity" is "something that has separate and distinct existence and objective or conceptual reality" [21]. Unfortunately, the definition for "entity" in HTTP/1.1 is similar to that used in MIME [12], based on a false analogy between MIME and HTTP.
「実体」の辞書的定義は「分離された異なる存在ならびに物体的または概念的現実性を有するもの」です。 不幸にも、 HTTP/1.1 の「実体」の定義は MIME で使われているものと同様で、 完全に間違った MIME と HTTP との類似性に基づいています。
In MIME, electronic mail messages do have distinct and separate existences. MIME defines "entity" as something that "refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity."
MIME では、電子メイル・メッセージは異なる分離された存在を有していました。 MIME は「実体」を「メッセージまたは多部分実体の本体中の部分の一つのいずれかの MIME 定義頭欄および内容を特に指す」ものとして定義しています。
In HTTP, however, a response message to a GET does not have a distinct and separate existence. Rather, it reflects the current state of a resource (or a variant, subject to a set of constraints). The HTTP/1.1 specification has no term to describe "the value that would be returned in response to a GET request at the current time for the selected variant of the specified resource." This leads to awkward wordings in the HTTP/1.1 specification in places where this concept is necessary.
しかし、 HTTP では、 GET に対する応答メッセージは異なる分離された存在を有していません。
むしろ、応答メッセージは資源の現在の状態 (制約の集合の対象となる、変体)
を記述しています。 HTTP/1.1 仕様書は「指定された資源の選択された変体についての現時点で
GET 要求に対する応答で返されることになる値」
を記述する用語を提供していません。このために、 HTTP/1.1
仕様書でこの概念が必要なところでぐちゃぐちゃした言い方をしています。
To express this concept, we define a new term, for use in this document:
HTTP/1.1 仕様書での用語遣いの失敗を修正するのにはもう遅すぎますので、 代わりにこの文書で使用するために新しい用語を定義します。
- instance
- The entity that would be returned in a status-200 response to a GET request, at the current time, for the selected variant of the specified resource, with the application of zero or more content-codings, but without the application of any instance manipulations (see below) or transfer-codings.
GET 要求に対する状態
200 の応答で、現時点において返されるであろう、
零個以上の内容符号化を適用した、
実現値操作や転送符号化は適用していない実体。It is convenient to think of an entity tag, in HTTP/1.1, as being associated with an instance, rather than an entity. That is, for a given resource, two different response messages might include the same entity tag, but two different instances of the resource should never be associated with the same (strong) entity tag.
HTTP/1.1 の実体札は、実体と関連付けられていると考えるよりは、 実現値と関連付けられていると考えた方が便利です。 すなわち、ある資源について、二つの異なる応答メッセージは同じ実体札を返すかもしれませんが、 その資源の二つの異なる実現値は決して同じ (強い) 実体札に関連付けられるべきではありません。
Preference-Applied: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"
[36] RFC 8144 - Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) () https://tools.ietf.org/html/rfc8144#section-3