付録 A. リソース表現と表現データ

The following examples show how representation metadata, content transformations, and methods impact the message and content. These examples a not exhaustive.

以下の例は、表現メタデータ、コンテンツ変換、およびメソッドがメッセージとコンテンツにどのように影響するかを示しています。これらの例は網羅的なものではありません。

Unless otherwise indicated, the examples are based on the JSON object {"hello": "world"} followed by an LF. When the content contains non-printable characters (e.g., when it is encoded), it is shown as a sequence of hex-encoded bytes.

特に明記しない限り、例は LF が続く JSON オブジェクト {"hello": "world"} に基づいています。コンテンツに印刷不可能な文字が含まれている場合（エンコードされている場合など）、16進エンコードされたバイトのシーケンスとして表示されます。

Consider a client that wishes to upload a JSON object using the PUT method. It could do this using the application/json Content-Type without any content coding.

PUT メソッドを使用して JSON オブジェクトをアップロードしたいクライアントを考えてみましょう。これは、コンテンツコーディングなしで application/json Content-Type を使用して行うことができます。

PUT /entries/1234 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Length: 19

{"hello": "world"}

Figure 1: Request Containing a JSON Object without Any Content Coding

図 1：コンテンツコーディングなしの JSON オブジェクトを含むリクエスト

However, the use of content coding is quite common. The client could also upload the same data with a GZIP coding (Section 8.4.1.3 of [HTTP]). Note that in this case, the Content-Length contains a larger value due to the coding overheads.

ただし、コンテンツコーディングの使用は非常に一般的です。クライアントは、GZIP コーディング（[HTTP] のセクション 8.4.1.3）を使用して同じデータをアップロードすることもできます。この場合、コーディングのオーバーヘッドにより、Content-Length に大きな値が含まれることに注意してください。

PUT /entries/1234 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 39

1F 8B 08 00 88 41 37 64 00 FF
AB 56 CA 48 CD C9 C9 57 B2 52
50 2A CF 2F CA 49 51 AA E5 02
00 D9 E4 31 E7 13 00 00 00

Figure 2: Request Containing a GZIP-Encoded JSON Object

図 2：GZIP エンコードされた JSON オブジェクトを含むリクエスト

Sending the GZIP-coded data without indicating it via Content-Encoding means that the content is malformed. In this case, the server can reply with an error.

Content-Encoding で示さずに GZIP コード化されたデータを送信することは、コンテンツが不正であることを意味します。この場合、サーバーはエラーで応答できます。

PUT /entries/1234 HTTP/1.1
Host: foo.example
Content-Type: application/json

Content-Length: 39

1F 8B 08 00 88 41 37 64 00 FF
AB 56 CA 48 CD C9 C9 57 B2 52
50 2A CF 2F CA 49 51 AA E5 02
00 D9 E4 31 E7 13 00 00 00

Figure 3: Request Containing Malformed JSON

図 3：不正な JSON を含むリクエスト

HTTP/1.1 400 Bad Request

Figure 4: An Error Response for Malformed Content

図 4：不正なコンテンツに対するエラー応答

A Range-Request affects the transferred message content. In this example, the client is accessing the resource at /entries/1234, which is the JSON object {"hello": "world"} followed by an LF. However, the client has indicated a preferred content coding and a specific byte range.

範囲リクエストは、転送されるメッセージコンテンツに影響します。この例では、クライアントは /entries/1234 のリソースにアクセスしています。これは、LF が続く JSON オブジェクト {"hello": "world"} です。ただし、クライアントは優先コンテンツコーディングと特定のバイト範囲を示しています。

GET /entries/1234 HTTP/1.1
Host: foo.example
Accept-Encoding: gzip
Range: bytes=1-7

Figure 5: Request for Partial Content

図 5：部分コンテンツのリクエスト

The server satisfies the client request by responding with a partial representation (equivalent to the first 10 bytes of the JSON object displayed in whole in Figure 2).

サーバーは、部分的な表現（図 2 で全体が表示されている JSON オブジェクトの最初の 10 バイトに相当）で応答することにより、クライアントのリクエストを満たします。

HTTP/1.1 206 Partial Content
Content-Encoding: gzip
Content-Type: application/json
Content-Range: bytes 0-9/39

1F 8B 08 00 A5 B4 BD 62 02 FF

Figure 6: Partial Response from a GZIP-Encoded Representation

図 6：GZIP エンコードされた表現からの部分応答

Aside from content coding or range requests, the method can also affect the transferred message content. For example, the response to a HEAD request does not carry content, but this example case includes Content-Length; see Section 8.6 of [HTTP].

コンテンツコーディングや範囲リクエストとは別に、メソッドも転送されるメッセージコンテンツに影響を与える可能性があります。たとえば、HEAD リクエストへの応答はコンテンツを運びませんが、この例の場合は Content-Length が含まれています。[HTTP] のセクション 8.6 を参照してください。

HEAD /entries/1234 HTTP/1.1
Host: foo.example
Accept: application/json
Accept-Encoding: gzip

Figure 7: HEAD Request

図 7：HEAD リクエスト

HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 39

Figure 8: Response to HEAD Request (Empty Content)

図 8：HEAD リクエストへの応答（空のコンテンツ）

Finally, the semantics of a response might decouple the target URI from the enclosed representation. In the example below, the client issues a POST request directed to /authors/, but the response includes a Content-Location header field indicating that the enclosed representation refers to the resource available at /authors/123. Note that Content-Length is not sent in this example.

最後に、応答のセマンティクスにより、ターゲット URI が同封された表現から切り離される場合があります。以下の例では、クライアントは /authors/ 宛ての POST リクエストを発行しますが、応答には Content-Location ヘッダーフィールドが含まれており、同封された表現が /authors/123 で利用可能なリソースを参照していることを示しています。この例では Content-Length が送信されないことに注意してください。

POST /authors/ HTTP/1.1
Host: foo.example
Accept: application/json
Content-Type: application/json

{"author": "Camilleri"}

Figure 9: POST Request

図 9：POST リクエスト

HTTP/1.1 201 Created
Content-Type: application/json
Content-Location: /authors/123
Location: /authors/123

{"id": "123", "author": "Camilleri"}

Figure 10: Response with Content-Location Header

図 10：Content-Location ヘッダーを含む応答