/
233.txt
94 lines (73 loc) · 5.56 KB
/
233.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
[305] [DFN[[RUBYB[[[表現]]]@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]] 版) <https://tools.ietf.org/html/rfc7231#section-3>
-- [306] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-3.1>
- [3] [CITE@en[RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests]] ([TIME[2014-09-11 10:02:44 +09:00]] 版) <https://tools.ietf.org/html/rfc7232#section-2.1>
- [9] [CITE@en[RFC 7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests]] ([TIME[2014-09-11 10:02:44 +09:00]] 版) <https://tools.ietf.org/html/rfc7232#section-4.1>
]REFS]
* 定義
[8] [[RFC 7231]] は、次のように説明しています [SRC[>>6]]。
>
[7] [[資源]]は何であっても良いとし、 [[HTTP]] が提供する一様なインターフェイスが独立した他者に対する[[メッセージ]]のやり取りによってだけそれを観察したり作用したりできるような[[窓]]のようなものであると考えると、
やり取りにおいてそれの現在の状態や望む状態を表現する (代わりとなる)
抽象化が必要となります。この抽象化を、[[表現]]と呼びます [SRC[[[REST]]]]。
>
[[HTTP]] においては、「[[表現]]」は、特定の[[資源]]の過去や現在の、あるいは望ましい状態を反映することを意図した情報であって、
[[プロトコル]]を通じて通信することができる形式にあるもので、
[[表現メタデータ]]の集合と表現データの無限かもしれない[[ストリーム]]によって構成されるものです。
>
[[起源鯖]]は、[[対象資源]]の現在の状態を反映することを意図した複数の[[表現]]を提供されていたり、
[[生成]]することができたりします。そのような場合、
特定の[[要求]]に最も適切な、通常は[[内容折衝]]に基づく、
いずれかの[[表現]]を[[起源鯖]]が選択するアルゴリズムが用いられます。
この「選択された表現」は、[[条件付き要求]]の評価や
[CODE(HTTP)@en[[[GET]]]] に対する [CODE(HTTP)[[[200]]]] や [CODE(HTTP)[[[304]]]]
の[[応答]]の [[payload]] の構築でデータやメタデータとして使われます。
[310] ところで[[要求メッセージ]]の [[payload]] に含まれるデータのことや、
[CODE(HTTP)[[[404]]]] や [CODE(HTTP)[[[303]]]] などの[[応答]]の [[payload]]
に含まれるデータのことも[[表現]]と呼ばれているようですが、
これらも定義上の[[表現]]の範囲に入っているのかはよくわかりません。
少なくても [CODE(HTTP)[[[200]]]] で [[payload]] に含まれる“[[対象資源]]の”[[表現]]とは異なるものとして扱われているようですが...
;; [405] [[資源]]と[[表現]]は、平易な表現に見えて実は難解な [[HTTP]]
の専門用語の代表格といえます。 [[HTTP]] [[RFC]] の著者達以外に正しく理解している人がどれだけいるのでしょう。
;; [406] 概念の [[overengineering]] な気もしますが...
;; [2] 「[[選択された表現]]」は [[RFC 3229]]/[[RFC 3230]] の[[実現値]]と同じ意味かもしれません。
* ヘッダー
[307] 次の[[ヘッダー]]は、[DFN[[RUBYB[[[表現メタデータ]]]@en[representation metadata]]]]に分類されています
[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]]]] の規定においてはこの広い意味の[[表現メタデータ]]が使われています。
* 歴史
[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]
[5]
>
: [DFN[[RUBYB[表現]@en[representation]]]]:
[[RFC 2616]] で定義されている通り[[要求]]や[[応答]]に含まれる[[実体]]。
;; [CITE@en[RFC 5023 - The Atom Publishing Protocol]] ([TIME[2008-11-20 18:52:14 +09:00]] 版) <http://tools.ietf.org/html/rfc5023#section-3>