Accept

Accept 헤더는 클라이언트에서 승인 및 이해할 수 있는 서버에서 리턴되는 잠재적 데이터 유형의 목록을 지정합니다. 형식은 콜론으로 구분된 하나 이상의 MIME 유형의 목록입니다.

대부분의 요청에서 승인된 목록에는 JSON 데이터(application/json)가 포함되어 있어야 합니다.

첨부 파일의 경우 명시적으로 MIME 유형을 지정하거나 */*를 사용하여 모든 파일 유형이 지원되도록 지정할 수 있습니다.

Accept 헤더가 제공되지 않을 경우 서버는 클라이언트에서 모든 형식을 승인함을 의미하는 */* MIME 유형을 사용하는 것으로 가정합니다.

명시적 Accept 헤더 없이 요청을 전송하거나 */*를 지정하는 경우 다음 예제를 참조하십시오.

GET /recipes HTTP/1.1
Host: username.cloudant.com
Accept: */*

클라이언트가 모든 형식을 허용하는 것으로 가정할 때 리턴되는 헤더의 다음 예제를 참조하십시오.

리턴되는 컨텐츠 유형은 요청을 통해 리턴되는 정보가 JSON 형식인 경우에도 text/plain입니다.

Server: CouchDB/1.0.2 (Erlang OTP/R14B)
Date: Thu, 13 Jan 2011 13:39:34 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: #7
Cache-Control: must-revalidate

IBM Cloudant에 대한 조회의 경우 Accept를 반드시 사용할 필요는 없지만 클라이언트에서 리턴되는 데이터를 처리할 수 있도록 해주는 데 도움이 되기 때문에 적극 권장합니다.

Accept 헤더를 사용하는 데이터 유형을 지정하는 경우, IBM Cloudant에서는 응답의 Content-type 헤더 필드의 지정된 유형을 따릅니다. 예를 들어 요청의 application/json에서 명시적으로 Accept을 요청하는 경우 리턴되는 HTTP 헤더는 리턴되는 Content-type 필드에서 이 유형을 사용합니다.

다음과 같이 명시적으로 Accept 헤더를 지정하는 요청 예제를 참조하십시오.

GET /recipes HTTP/1.1
Host: username.cloudant.com
Accept: application/json

다음과 같이 application/json 컨텐츠 유형을 포함하여 응답에서 리턴되는 헤더의 예제를 참조하십시오.

Server: CouchDB/1.0.2 (Erlang OTP/R14B)
Date: Thu, 13 Jan 2011 13:40:11 GMT
Content-Type: application/json
Content-Length: #7
Cache-Control: must-revalidate

요청 헤더의 Content-Type

Content-Type 헤더는 요청 내에서 제공되는 정보에 대한 컨텐츠 유형을 지정합니다. 이 스펙에서는 MIME 유형 스펙을 사용합니다. 대부분의 요청에서 컨텐츠 유형은 JSON(application/json)입니다.

일부 설정의 경우 MIME 유형이 일반 텍스트입니다.

특히 첨부 파일을 업로드하는 경우 이 유형이 첨부 파일 또는 2진(application/octet-stream)에 해당하는 MIME 유형이어야 합니다.

요청에서 Content-Type을 사용할 것을 적극 권장합니다.

Content-Encoding

Content-Encoding 헤더는 요청 본문의 인코딩을 지정합니다. 지원되는 값은 gzip입니다. 이 헤더를 사용하는 경우 요청 본문이 해당 형식으로 인코딩되어야 합니다.

다음과 같이 gzipped로 인코딩된 요청 본문의 예제를 참조하십시오.

# create gzipped document
echo '{"foo":"bar"}' | gzip > doc.gzip

다음과 같이 HTTP를 사용하여 문서를 작성하기 위해 gzip으로 인코딩된 요청 본문을 전송하는 예제를 참조하십시오.

PUT /db/doc HTTP/1.1
HOST: example.cloudant.com
Content-Encoding: gzip

다음과 같이 명령행을 사용하여 문서를 작성하기 위해 gzip으로 인코딩된 요청 본문을 전송하는 예제를 참조하십시오.

curl "https://example.cloudant.com/db/doc" \
	-X PUT \
	-T doc.gzip \
	-H "Content-Encoding: gzip"

기본적으로 SDK는 요청 본문을 압축합니다.

If-None-Match

If-None-Match 헤더는 선택사항입니다. 문서를 마지막으로 읽어들이거나 업데이트한 후 해당 문서가 수정되었는지 여부를 판별하기 위해 이 헤더를 전송할 수 있습니다. If-None-Match 헤더의 값은 수신된 마지막 Etag 값과 일치해야 합니다. 값이 문서의 현재 개정과 일치하면 서버가 304 Not Modified 상태 코드를 보내고 응답 자체에 본문이 없습니다.

문서가 수정된 경우, 문서가 여전히 존재하고 다른 오류가 발생하지 않은 경우 정상적인 200 응답이 표시됩니다.

Cache-Control

Cache-Control HTTP 응답 헤더는 리턴된 정보를 처리하는 방법에 대한 클라이언트 캐시 메커니즘의 제안사항을 제공합니다. IBM Cloudant에서는 일반적으로 가능한 경우 정보를 재인증해야 함을 나타내는 must-revalidate 값을 리턴합니다. 재인증을 통해 컨텐츠의 동적 네이처가 올바르가 업데이트되었는지 확인할 수 있습니다.

Content-Length

Content-Length 헤더는 리턴되는 컨텐츠의 길이(바이트)를 보고합니다.

응답 헤더의 Content-Type

Content-Type 헤더는 리턴되는 데이터의 MIME 유형을 지정합니다. 대부분의 요청에서 리턴되는 MIME 유형은 text/plain입니다. 모든 텍스트는 유니코드(UTF-8)로 인코딩되며, 이 내용은 리턴되는 Content-Type에서 명시적으로 text/plain;charset=utf-8로 표시되어 있습니다.

Etag

Etag 헤더는 문서의 개정을 표시하는 데 사용됩니다. 문서의 경우 이 값이 해당 문서의 개정판과 동일합니다. 개정이 여전히 최신인 경우 If-None-Match 요청 헤더와 함께 값을 사용하여 304 Not Modified 응답을 가져올 수 있습니다.

해당 요청에서 리턴된 ETag가 모든 요청에 대해 변경되는 난수이므로, ETag는 현재는 뷰에서 사용할 수 없습니다.