representation headers

表現 (HTTP)

[305] HTTP における (ひょう) (げん) (representation) とは、 読み書きその他の処理の対象となるデータのことをいいます。

仕様書

定義

[8] RFC 7231 は、次のように説明しています >>6

[7] 資源は何であっても良いとし、 HTTP が提供する一様なインターフェイスが独立した他者に対するメッセージのやり取りによってだけそれを観察したり作用したりできるようなのようなものであると考えると、 やり取りにおいてそれの現在の状態や望む状態を表現する (代わりとなる) 抽象化が必要となります。この抽象化を、表現と呼びます REST

HTTP においては、「表現」は、特定の資源の過去や現在の、あるいは望ましい状態を反映することを意図した情報であって、 プロトコルを通じて通信することができる形式にあるもので、 表現メタデータの集合と表現データの無限かもしれないストリームによって構成されるものです。

起源鯖は、対象資源の現在の状態を反映することを意図した複数の表現を提供されていたり、 生成することができたりします。そのような場合、 特定の要求に最も適切な、通常は内容折衝に基づく、 いずれかの表現起源鯖が選択するアルゴリズムが用いられます。 この「選択された表現」は、条件付き要求の評価や GET に対する 200304応答payload の構築でデータやメタデータとして使われます。

[405] 資源表現は、平易な表現に見えて実は難解な HTTP の専門用語の代表格といえます。 HTTP RFC の著者達以外に正しく理解している人がどれだけいるのでしょう。
[406] 概念の overengineering な気もしますが...

[34] HTML Standard は、 HTTP などいくつかの仕様書のいう表現HTML Standard における資源 (resource) である >>33 と定義しています。

選択された表現

[11] 表現の候補が1つ以上ある場合に、内容折衝などの条件によって選ばれた表現のことを特に選択された表現 (selected representation) と呼んでいます。

[12]GET メソッドだったら返されるであろう表現」 のような呼ばれ方をしているものと同じと思われます。

[27] ただし「PUT メソッドGET メソッドで返される表現を置き換える」と言った場合に内容表現の影響をどう評価しているのかは、 これだけからは明らかではありません。

[28] WebDAV は「accept header なしの GET で返される」といった言い方を使っています。

[2]選択された表現」は RFC 3229/RFC 3230実現値とほぼ同じ意味に見えますが、 明言されておらずはっきりしません。

[24] (じつ) (げん) () (インスタンス) (instance) は、 その時点で指定された資源の選択された異体に対しての GET 要求への状態符号200応答で返されるであろう実体で、 0個以上の内容符号化の適用後であって、実現値操作転送符号化の適用前のものをいいます >>22, >>26

[25] RFC 723x 世代の用語だと実体payload と読み替える感じでしょうか。

[13] 選択された表現は、応答メッセージに含まれるとは限りません。例えば PUT では選択された表現が新たなものに変更されますが、 変更の前の表現も後の表現応答メッセージに含まれるとは限りません。

対象資源以外の表現

[310] ところで要求メッセージpayload に含まれるデータのことや、 404303 などの応答payload に含まれるデータのことも「表現」と呼ばれているようですが、 これらも定義上の表現の範囲に入っているのかはよくわかりません。 少なくても 200payload に含まれる“対象資源の”表現とは異なるものとして扱われているようですが...

現在の表現

[14] 対象資源表現は、時を経て変更されることがあります。 ある時点での状態を指す時に現在の表現 (current representation) という言葉が使われます。

[15] 内容折衝のために現在の表現が複数存在するかもしれません。

ヘッダー

[307] 次のヘッダーは、表現メタデータ (representation metadata) (表現ヘッダー (representation header (field)) ) に分類されています >>306

[10] Content-* がすべて表現メタデータではありません。 Content-Range:Content-Length:payload header に分類されています。

[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 に指定する引数として、次のものがあります。

処理

[3] Prefer:, return も参照。

[20] Prefer: return=representation が指定された場合、 応答payload body は当該要求の処理の適用後の適用対象の資源表現とすることが期待されています。

[21] その際、当該表現実効要求URL表現ではなく、他の資源表現である場合もあります。その場合は返された表現URLContent-Location: ヘッダーで指定できます >>18

歴史

HTTP RFC

[1] HTTP (RFC 2068 1.3, RFC 2616 1.3)
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.
表現
内容折衝の対象である応答に含まれている実体。 特定の応答状態に関連付けられた複数の表現が存在するかもしれない。
[5] RFC 5023 - The Atom Publishing Protocol ( 版) http://tools.ietf.org/html/rfc5023#section-3
表現 (representation)
RFC 2616 で定義されている通り要求応答に含まれる実体

差分符号化

[23] RFC 3229 (差分符号化), RFC 3230 (要約) の用語定義より抜粋

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 の実体札は、実体と関連付けられていると考えるよりは、 実現値と関連付けられていると考えた方が便利です。 すなわち、ある資源について、二つの異なる応答メッセージは同じ実体札を返すかもしれませんが、 その資源の二つの異なる実現値は決して同じ (強い) 実体札に関連付けられるべきではありません。

[35] RESTful HTTP API - Fedora 4.0 Documentation - DuraSpace Wiki () https://wiki.duraspace.org/display/FEDORA40/RESTful+HTTP+API

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