[305] [[HTTP]] における[DFN[[RUBYB[[RUBY[表][ひょう]][RUBY[現][げん]]]@en[representation]]]]とは、 読み書きその他の処理の対象となるデータのことをいいます。 * 仕様書 [REFS[ - [6] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) -- [306] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) - [3] [CITE@en[RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests]] ([TIME[2014-09-11 10:02:44 +09:00]] 版) - [9] [CITE@en[RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests]] ([TIME[2014-09-11 10:02:44 +09:00]] 版) - [16] [CITE@en[RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests]] ([TIME[2014-09-11 09:57:55 +09:00]] 版) - [22] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) - [26] [CITE@en[RFC 3230 - Instance Digests in HTTP]] ([TIME[2014-08-31 18:57:37 +09:00]] 版) - [18] [CITE@en[RFC 7240 - Prefer Header for HTTP]] ([TIME[2014-07-26 04:24:01 +09:00]] 版) - [33] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2016-04-03 15:54:50 +09:00]] 版) ]REFS] * 定義 [8] [[RFC 7231]] は、次のように説明しています [SRC[>>6]]。 > [7] [[資源]]は何であっても良いとし、 [[HTTP]] が提供する一様なインターフェイスが独立した他者に対する[[メッセージ]]のやり取りによってだけそれを観察したり作用したりできるような[[窓]]のようなものであると考えると、 やり取りにおいてそれの現在の状態や望む状態を表現する (代わりとなる) 抽象化が必要となります。この抽象化を、[[表現]]と呼びます [SRC[[[REST]]]]。 > [[HTTP]] においては、「[[表現]]」は、特定の[[資源]]の過去や現在の、あるいは望ましい状態を反映することを意図した情報であって、 [[プロトコル]]を通じて通信することができる形式にあるもので、 [[表現メタデータ]]の集合と表現データの無限かもしれない[[ストリーム]]によって構成されるものです。 > [[起源鯖]]は、[[対象資源]]の現在の状態を反映することを意図した複数の[[表現]]を提供されていたり、 [[生成]]することができたりします。そのような場合、 特定の[[要求]]に最も適切な、通常は[[内容折衝]]に基づく、 いずれかの[[表現]]を[[起源鯖]]が選択するアルゴリズムが用いられます。 この「選択された表現」は、[[条件付き要求]]の評価や [CODE(HTTP)@en[[[GET]]]] に対する [CODE(HTTP)[[[200]]]] や [CODE(HTTP)[[[304]]]] の[[応答]]の [[payload]] の構築でデータやメタデータとして使われます。 ;; [405] [[資源]]と[[表現]]は、平易な表現に見えて実は難解な [[HTTP]] の専門用語の代表格といえます。 [[HTTP]] [[RFC]] の著者達以外に正しく理解している人がどれだけいるのでしょう。 ;; [406] 概念の [[overengineering]] な気もしますが... [34] [[HTML Standard]] は、 [[HTTP]] などいくつかの[[仕様書]]のいう[[表現]]が [[HTML Standard]] における[DFN[[RUBYB[[[資源]]]@en[resource]]]]である [SRC[>>33]] と定義しています。 * 選択された表現 [11] [[表現]]の候補が1つ以上ある場合に、[[内容折衝]]などの条件によって選ばれた[[表現]]のことを特に[DFN[[RUBYB[[[選択された表現]]]@en[selected representation]]]]と呼んでいます。 [12] 「[CODE(HTTP)@en[[[GET]]]] [[メソッド]]だったら返されるであろう[[表現]]」 のような呼ばれ方をしているものと同じと思われます。 [27] ただし「[CODE(HTTP)@en[[[PUT]]]] [[メソッド]]が [CODE(HTTP)@en[[[GET]]]] [[メソッド]]で返される[[表現]]を置き換える」と言った場合に[[内容表現]]の影響をどう評価しているのかは、 これだけからは明らかではありません。 [28] [[WebDAV]] は「[[accept header]] なしの [CODE(HTTP)@en[[[GET]]]] で返される」といった言い方を使っています。 [2] 「[[選択された表現]]」は [[RFC 3229]]/[[RFC 3230]] の[[実現値]]とほぼ同じ意味に見えますが、 明言されておらずはっきりしません。 [24] [DFN[[RUBYB[[RUBYB[[RUBY[実][じつ]][RUBY[現][げん]][RUBY[値][ち]]]@en[インスタンス]]]@en[instance]]]]は、 その時点で指定された[[資源]]の選択された[[異体]]に対しての [CODE(HTTP)@en[[[GET]]]] [[要求]]への[[状態符号]]が [CODE(HTTP)[[[200]]]] の[[応答]]で返されるであろう[[実体]]で、 0個以上の[[内容符号化]]の適用後であって、[[実現値操作]]や[[転送符号化]]の適用前のものをいいます [SRC[>>22, >>26]]。 ;; [25] [[RFC 723x]] 世代の用語だと[[実体]]は [[payload]] と読み替える感じでしょうか。 [13] [[選択された表現]]は、[[応答メッセージ]]に含まれるとは限りません。例えば [CODE(HTTP)@en[[[PUT]]]] では[[選択された表現]]が新たなものに変更されますが、 変更の前の[[表現]]も後の[[表現]]も[[応答メッセージ]]に含まれるとは限りません。 * 対象資源以外の表現 [310] ところで[[要求メッセージ]]の [[payload]] に含まれるデータのことや、 [CODE(HTTP)[[[404]]]] や [CODE(HTTP)[[[303]]]] などの[[応答]]の [[payload]] に含まれるデータのことも「[[表現]]」と呼ばれているようですが、 これらも定義上の[[表現]]の範囲に入っているのかはよくわかりません。 少なくても [CODE(HTTP)[[[200]]]] で [[payload]] に含まれる“[[対象資源]]の”[[表現]]とは異なるものとして扱われているようですが... * 現在の表現 [14] [[対象資源]]の[[表現]]は、時を経て変更されることがあります。 ある時点での状態を指す時に[RUBYB[現在の表現]@en[current representation]]という言葉が使われます。 ;; [15] [[内容折衝]]のために現在の[[表現]]が複数存在するかもしれません。 * ヘッダー [307] 次の[[ヘッダー]]は、[DFN[[RUBYB[[[表現メタデータ]]]@en[representation metadata]]]] ([DFN[[RUBYB[表現ヘッダー]@en[representation header (field)]]]]) に分類されています [SRC[>>306]]。 [FIG(list short)[ - [CODE(HTTP)@en[[[Content-Type:]]]] - [CODE(HTTP)@en[[[Content-Encoding:]]]] - [CODE(HTTP)@en[[[Content-Language:]]]] - [CODE(HTTP)@en[[[Content-Location:]]]] ]FIG] ;; [10] [CODE(HTTP)@en[[[Content-*]]]] がすべて[[表現メタデータ]]ではありません。 [CODE(HTTP)@en[[[Content-Range:]]]] や [CODE(HTTP)@en[[[Content-Length:]]]] は [[payload header]] に分類されています。 [308] [[メッセージ]]に [[payload body]] が含まれるときは、 [[payload body]] に含まれる[[表現]]データの解釈方法を表します [SRC[>>306]]。 [309] [CODE(HTTP)@en[[[HEAD]]]] [[要求]]に対する[[応答]]の時は、 [CODE(HTTP)@en[[[GET]]]] だった場合の[[応答]]に含まれる[[表現]]データの解釈方法を表します [SRC[>>306]]。 [4] [[RFC 7232]] は[[検証子]]のことを[[表現メタデータ]]と呼んでいますが [SRC[>>3, >>9]]、 [[検証子ヘッダー]]と >>307 は[[互いに素]]であり、両者の関係性は不明確です。 [CODE(HTTP)[[[304]]]] の規定においてはこの広い意味の[[表現メタデータ]]が使われています。 [17] [[RFC 7233]] は[[表現ヘッダー]] (representation header field) という用語を使っており [SRC[>>16]]、意味的には >>4 と同じものを指していそうですが、真の意図は不明です。 * [CODE(HTTP)@en[Prefer: return=representation]] [19] [CODE(HTTP)@en[[[Prefer:]] [[return]]=[DFN[[[representation]]]]]] は、 成功した[[要求]]に対する[[応答]]は[[資源]]の現在の状態の[[表現]]とするべきことを[[クライアント]]が望んでいることを示します [SRC[>>18]]。 ** 引数 [29] [CODE(HTTP)@en[[[Prefer:]] [[return]]=[[representation]]]] に指定する[[引数]]として、次のものがあります。 [FIG(short list)[ - [CODE(HTTP)@en[[[include]]]] - [CODE(HTTP)@en[[[max-triple-count]]]] - [CODE(HTTP)@en[[[max-member-count]]]] - [CODE(HTTP)@en[[[max-kbyte-count]]]] - [CODE(HTTP)@en[[[omit]]]] ]FIG] ;; [30] [[機械可読]]な一覧が >>32 の [[JSON]] データファイルにあります。 [REFS[ - [31] [CITE@en[data-web-defs/headers.txt at master · manakai/data-web-defs]] ([TIME[2015-07-01 15:16:28 +09:00]] 版) - [32] [CITE@en[data-web-defs/headers.json at master · manakai/data-web-defs]] ([TIME[2015-07-01 15:17:11 +09:00]] 版) ]REFS] ** 処理 ;; [3] [CODE(HTTP)@en[[[Prefer:]]]], [CODE(HTTP)@en[[[return]]]] も参照。 [20] [CODE(HTTP)@en[[[Prefer:]] [[return]]=[[representation]]]] が指定された場合、 [[応答]]の [[payload body]] は当該[[要求]]の処理の適用後の適用対象の[[資源]]の[[表現]]とすることが期待されています。 [21] その際、当該[[表現]]は[[実効要求URL]]の[[表現]]ではなく、他の[[資源]]の[[表現]]である場合もあります。その場合は返された[[表現]]の [[URL]] を [CODE(HTTP)@en[[[Content-Location:]]]] [[ヘッダー]]で指定できます [SRC[>>18]]。 * 歴史 ** HTTP RFC [FIG(quote)[ [FIGCAPTION[ [1] [[HTTP]] ([[RFC 2068]] 1.3, [[RFC 2616]] 1.3) ]FIGCAPTION] > :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. :表現: [[内容折衝]]の対象である応答に含まれている[[実体]]。 特定の応答状態に関連付けられた複数の表現が存在するかもしれない。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [5] [CITE@en[RFC 5023 - The Atom Publishing Protocol]] ([TIME[2008-11-20 18:52:14 +09:00]] 版) ]FIGCAPTION] > : [DFN[[RUBYB[表現]@en[representation]]]]: [[RFC 2616]] で定義されている通り[[要求]]や[[応答]]に含まれる[[実体]]。 ]FIG] ** 差分符号化 [FIG(quote)[ [FIGCAPTION[ [23] RFC 3229 (差分符号化), RFC 3230 (要約) の用語定義より抜粋 ]FIGCAPTION] > 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 では、 [CODE(HTTP)[[[GET]]]] に対する[[応答メッセージ]]は異なる分離された存在を有していません。 むしろ、応答メッセージは資源の現在の状態 (制約の集合の対象となる、[[変体]]) を記述しています。 HTTP/1.1 仕様書は「指定された資源の選択された変体についての現時点で [CODE(HTTP)[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. :実現値: 特定の[[資源]]の選択された[[変体]]について、 [CODE(HTTP)[[[GET]]]] [[要求]]に対する[[状態]] [CODE(HTTP)[[[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 の[[実体札]]は、実体と関連付けられていると考えるよりは、 実現値と関連付けられていると考えた方が便利です。 すなわち、ある資源について、二つの異なる[[応答メッセージ]]は同じ実体札を返すかもしれませんが、 その資源の二つの異なる実現値は決して同じ (強い) 実体札に関連付けられるべきではありません。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [35] [CITE[RESTful HTTP API - Fedora 4.0 Documentation - DuraSpace Wiki]] ([TIME[2017-03-02 23:31:18 +09:00]]) ]FIGCAPTION] > Preference-Applied: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment" > ]FIG] [36] [CITE@en[RFC 8144 - Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2017-04-19 23:22:44 +09:00]])