경고: 이 페이지는 Google의 이전 API인 Google Data API에 관한 것으로, Google Data API 디렉터리에 표시된 API 중 상당수가 최신 API로 대체된 API입니다. 특정 새 API에 대한 자세한 내용은 새 API 문서를 참조하세요. 최신 API를 사용하여 요청을 승인하는 방법은 Google 계정 인증 및 승인을 참고하세요.
이 문서에서는 검색어가 표시되는 방식, 결과의 모양 등에 대한 정보를 비롯하여 여러 Google API에서 사용하는 Google 데이터 프로토콜을 설명합니다.
Google 데이터 프로토콜에 대한 자세한 내용은 개발자 가이드 개요 페이지와 프로토콜 기본사항 문서를 참고하세요.
대상
이 문서는 Google 데이터 프로토콜을 구현하는 API에서 사용하는 XML 형식 및 프로토콜의 세부정보를 확인하려는 사용자를 대상으로 합니다.
이러한 API 중 하나를 사용하는 코드만 작성하려는 경우 이러한 세부정보를 알 필요가 없습니다. 대신 언어별 클라이언트 라이브러리를 사용하면 됩니다.
프로토콜을 이해하려면 이 문서를 읽어보세요. 예를 들어 다음과 같은 작업에 도움이 되도록 이 문서를 읽어볼 수 있습니다.
- Google 데이터 프로토콜 아키텍처 평가
- 제공된 클라이언트 라이브러리를 사용하지 않고 프로토콜을 사용하여 코딩
- 새로운 언어로 클라이언트 라이브러리 작성
이 문서에서는 사용자가 HTTP, XML, 네임스페이스, 신디케이션 피드, GET, POST, PUT, DELETE 요청의 기본사항과 HTTP의 '리소스' 개념을 이해하고 있다고 가정합니다. 이에 대한 자세한 내용은 이 문서의 추가 리소스 섹션을 참고하세요.
이 문서에서는 특정 프로그래밍 언어를 사용하지 않습니다. HTTP 요청을 보내고 XML 기반 응답을 파싱할 수 있는 프로그래밍 언어를 사용하여 Google 데이터 프로토콜 메시지를 주고받을 수 있습니다.
프로토콜 세부정보
이 섹션에서는 Google 데이터 프로토콜 문서 형식과 쿼리 구문을 설명합니다.
문서 형식
Google 데이터 프로토콜과 Atom은 일부 전역 데이터와 모든 항목을 보유하는 컨테이너인 동일한 기본 데이터 모델을 공유합니다. 각 프로토콜의 형식은 기본 스키마에 의해 정의되지만 외부 네임스페이스를 사용하여 확장될 수 있습니다.
Atom은 Google 데이터 프로토콜의 기본 형식입니다. 다른 형식의 응답을 요청하려면 alt 쿼리 매개변수를 사용합니다. 자세한 내용은 쿼리 요청을 참고하세요.
참고: Atom 형식의 대부분의 Google 데이터 프로토콜 피드는 피드 요소에 xmlns 속성을 지정하여 Atom 네임스페이스를 기본 네임스페이스로 사용합니다(프로토콜 기본사항의 예 참고). 따라서 이 문서의 예에서는 Atom 형식 피드의 요소에 atom:를 명시적으로 지정하지 않습니다.
다음 표에는 스키마 요소의 Atom 표현이 나와 있습니다. 이 표에서 언급되지 않은 모든 데이터는 일반 XML로 취급됩니다. 달리 명시되지 않는 한 특정 열의 XML 요소는 Atom 네임스페이스에 있습니다.
참고: 이 요약에서는 표준 XPath 표기법을 사용합니다. 특히 슬래시는 요소 계층 구조를, @ 기호는 요소의 속성을 나타냅니다.
다음 각 표에 강조표시된 항목이 필요합니다.
다음 표에는 Google 데이터 프로토콜 피드의 요소가 나와 있습니다.
| 피드 스키마 항목 | Atom 표현 |
|---|---|
| 피드 제목 | /feed/title |
| 피드 ID | /feed/id |
| 피드 HTML 링크 | /feed/link[@rel="alternate"]\[@type="text/html"]/@href |
| 피드 설명 | /feed/subtitle |
| 피드 언어 | /feed/@xml:lang |
| 피드 저작권 | /feed/rights |
| 피드 작성자 |
특정 경우에 필요합니다. Atom 사양을 참조하세요. |
| 피드 최종 업데이트 날짜 | /feed/updated(RFC 3339 형식) |
| 피드 카테고리 | /feed/category/@term |
| 피드 카테고리 체계 | /feed/category/@scheme |
| 피드 생성기 | /feed/generator/feed/generator/@uri |
| 피드 아이콘 | /feed/icon |
| 피드 로고 | /feed/logo |
다음 표는 Google 데이터 프로토콜 검색결과 피드의 요소를 보여줍니다. 프로토콜은 검색결과 피드에 일부 OpenSearch 1.1 응답 요소를 노출합니다.
| 검색결과 피드 스키마 항목 | Atom 표현 |
|---|---|
| 검색결과 수 | /feed/openSearch:totalResults |
| 검색결과 시작 색인 | /feed/openSearch:startIndex |
| 페이지당 검색결과 수 | /feed/openSearch:itemsPerPage |
다음 표에는 Google 데이터 프로토콜 항목의 요소가 나와 있습니다.
| 항목 스키마 항목 | Atom 표현 |
|---|---|
| 항목 ID | /feed/entry/id |
| 항목 제목 | /feed/entry/title |
| 항목 링크 | /feed/entry/link |
| 항목 요약 |
특정 경우에 필요합니다. Atom 사양을 참조하세요. |
| 응모 콘텐츠 |
콘텐츠 요소가 없으면 항목에 |
| 항목 작성자 |
특정 경우에 필요합니다. Atom 사양을 참조하세요. |
| 항목 카테고리 | /feed/entry/category/@term |
| 항목 카테고리 체계 | /feed/entry/category/@scheme |
| 항목 게시 날짜 | /feed/entry/published(RFC 3339) |
| 항목 업데이트 날짜 | /feed/entry/updated(RFC 3339) |
쿼리
이 섹션에서는 쿼리 시스템을 사용하는 방법을 설명합니다.
모델 설계 원칙 쿼리
쿼리 모델은 의도적으로 매우 간단합니다. 기본 원칙은 다음과 같습니다.
- 쿼리는 HTTP 헤더 또는 페이로드의 일부가 아니라 HTTP URI로 표현됩니다. 이 접근 방식의 한 가지 이점은 쿼리에 연결할 수 있다는 것입니다.
- 조건자의 범위는 단일 항목으로 지정됩니다. 따라서 '오늘 저에게 이메일을 10개 이상 보낸 사람의 모든 이메일을 찾아보세요'와 같은 상관관계 검색어를 보낼 수 있는 방법은 없습니다.
- 검색어를 예측할 수 있는 속성 집합은 매우 제한적입니다. 대부분의 검색어는 단순히 전체 텍스트 검색어입니다.
- 결과 순서는 구현에 따라 결정됩니다.
- 프로토콜은 기본적으로 확장 가능합니다. 서비스에서 추가 조건자 또는 정렬을 노출하려는 경우 새 매개변수를 도입하여 쉽게 할 수 있습니다.
쿼리 요청
클라이언트는 HTTP GET 요청을 실행하여 Google 서비스를 쿼리합니다. 쿼리 URI는 리소스 URI (Atom에서는 FeedURI)와 그 뒤에 나오는 쿼리 매개변수로 구성됩니다. 대부분의 쿼리 매개변수는 기존 ?name=value[&...] URL 매개변수로 표현됩니다. 카테고리 매개변수는 다르게 처리됩니다(아래 참고).
예를 들어, FeedURI가 http://www.example.com/feeds/jo이면 다음 URI를 사용하여 쿼리를 보낼 수 있습니다.
http://www.example.com/feeds/jo?q=Darcy&updated-min=2005-04-19T15:30:00Z
Google 데이터 프로토콜은 HTTP 조건부 GET를 지원합니다. 프로토콜을 구현하는 API는 반환된 피드 또는 항목의 <atom:updated> 요소 값을 기반으로 Last-Modified 응답 헤더를 설정합니다. 클라이언트는 콘텐츠가 변경되지 않았다면 콘텐츠가 다시 검색되지 않도록 이 값을 If-Modified-Since 요청 헤더의 값으로 다시 전송할 수 있습니다. If-Modified-Since 이후 콘텐츠가 변경되지 않으면 서비스에서 304 (Not Modified) HTTP 응답을 반환합니다.
Google 데이터 프로토콜을 구현하는 API는 alt 쿼리를 지원해야 합니다. 다른 매개변수 지원은 선택사항입니다. 특정 서비스에서 인식하지 못하는 표준 매개변수를 전달하면 403 Forbidden 응답이 발생합니다. 지원되지 않는 비표준 매개변수를 전달하면 400 Bad Request 응답이 발생합니다. 다른 상태 코드에 대한 자세한 내용은 이 문서의 HTTP 상태 코드 섹션을 참조하세요.
표준 쿼리 매개변수는 다음 표에 요약되어 있습니다. 모든 매개변수 값은 URL로 인코딩해야 합니다.
| 매개변수 | 의미 | 메모 |
|---|---|---|
alt |
대체 표현 유형 |
|
author |
항목 작성자 |
|
category |
카테고리 쿼리 필터 |
|
/-/category |
카테고리 쿼리 필터 |
|
| 항목 ID | 가져올 특정 항목의 ID |
|
fields |
응답 필터 |
|
max-results |
가져올 최대 결과 수 | 기본 피드 크기를 제한하기 위해 기본 max-results 값이 있는 서비스의 경우 전체 피드를 수신하려면 매우 큰 수를 지정할 수 있습니다. |
prettyprint |
ID 및 줄 바꿈이 포함된 XML 응답을 반환합니다. |
|
published-max published-min |
항목 게시 날짜의 경계 |
|
q |
전체 텍스트 쿼리 문자열 |
|
start-index |
가져올 첫 번째 결과의 1 기반 색인입니다. |
|
strict |
엄격한 쿼리 매개변수 확인 |
|
updated-max updated-min |
항목 업데이트 날짜 범위 |
|
카테고리 검색어에 대한 정보
Google에서는 카테고리 검색어에 약간 독특한 형식을 제공하기로 결정했습니다. 다음과 같은 쿼리가 필요하지 않습니다.
http://example.com/jo?category=Fritz&category=2006
다음을 사용할 수 있게 되었습니다.
http://example.com/jo/-/Fritz/2006
이 접근 방식은 쿼리 매개변수를 사용하지 않고 리소스를 식별하며 더 깔끔한 URI를 생성합니다. Google에서는 이 접근 방식을 선택했습니다. 카테고리 검색어가 가장 일반적인 쿼리 중 하나라고 생각하기 때문입니다.
이 접근 방식의 단점은 http://example.com/jo/MyPost/comments과 같은 다른 리소스 URI와 카테고리 쿼리를 구분할 수 있도록 이 유형의 카테고리 쿼리에 /-/를 사용해야 한다는 것입니다.
쿼리 응답
쿼리는 요청 매개변수에 따라 Atom 피드, Atom 항목 또는 RSS 피드를 반환합니다.
쿼리 결과에 <feed> 또는 <channel> 요소 바로 아래에 다음과 같은 OpenSearch 요소가 포함됩니다 (결과가 Atom인지 RSS인지에 따라 다름).
openSearch:totalResults- 쿼리의 총 검색결과 수입니다 (결과 피드에 반드시 포함되는 것은 아님).
openSearch:startIndex- 첫 번째 결과의 1부터 시작하는 색인입니다.
openSearch:itemsPerPage- 한 페이지에 표시되는 최대 항목 수입니다. 이렇게 하면 클라이언트가 임의의 후속 페이지 세트에 대한 직접 링크를 생성할 수 있습니다. 하지만 이 숫자 사용에 문제가 발생할 경우 쿼리 요청 섹션의 표에서
start-index관련 참고사항을 확인하세요.
Atom 응답 피드 및 항목에는 다음과 같은 Atom 및 Data API 요소 (Atom 사양에 나열된 다른 요소)도 포함될 수 있습니다.
<link rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml" href="..."/>- 전체 Atom 피드를 가져올 수 있는 URI를 지정합니다.
<link rel="http://schemas.google.com/g/2005#post" type="application/atom+xml" href="..."/>- Atom 피드의 PostURI (새 항목이 게시될 수 있음)를 지정합니다.
<link rel="self" type="..." href="..."/>- 이 리소스의 URI를 포함합니다.
type속성의 값은 요청된 형식에 따라 다릅니다. 그때까지 데이터가 변경되지 않으면 이 URI에 다른 GET을 전송하면 동일한 응답이 반환됩니다. <link rel="previous" type="application/atom+xml" href="..."/>- 청크된 경우 이 쿼리 결과 집합의 이전 청크 URI를 지정합니다.
<link rel="next" type="application/atom+xml" href="..."/>- 청크된 경우 이 쿼리 결과 세트의 다음 청크 URI를 지정합니다.
<link rel="edit" type="application/atom+xml" href="..."/>- Atom 항목의 EditURI (업데이트된 항목을 보내는 위치)를 지정합니다.
다음은 검색어에 대한 응답으로 표시되는 샘플 응답 본문입니다.
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:openSearch="http://a9.com/-/spec/opensearch/1.1/"
xmlns:gd='http://schemas.google.com/g/2005'
gd:etag='W/"C0QBRXcycSp7ImA9WxRVFUk."'>
<id>http://www.example.com/feed/1234.1/posts/full</id>
<updated>2005-09-16T00:42:06Z</updated>
<title type="text">Books and Romance with Jo and Liz</title>
<link rel="alternate" type="text/html" href="http://www.example.net/"/>
<link rel="http://schemas.google.com/g/2005#feed"
type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full"/>
<link rel="http://schemas.google.com/g/2005#post"
type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full"/>
<link rel="self" type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full"/>
<author>
<name>Elizabeth Bennet</name>
<email>liz@gmail.com</email>
</author>
<generator version="1.0"
uri="http://www.example.com">Example Generator Engine</generator>
<openSearch:totalResults>2</openSearch:totalResults>
<openSearch:startIndex>0</openSearch:startIndex>
<entry gd:etag='W/"C0QBRXcycSp7ImA9WxRVGUo."'>
<id>http://www.example.com/feed/1234.1/posts/full/4521614025009481151</id>
<published>2005-01-09T08:00:00Z</published>
<updated>2005-01-09T08:00:00Z</updated>
<category scheme="http://www.example.com/type" term="blog.post"/>
<title type="text">This is the title of entry 1009</title>
<content type="xhtml">
<div
xmlns="http://www.w3.org/1999/xhtml">This is the entry body of entry 1009</div>
</content>
<link rel="alternate" type="text/html"
href="http://www.example.com/posturl"/>
<link rel="edit" type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full/4521614025009481151"/>
<author>
<name>Elizabeth Bennet</name>
<email>liz@gmail.com</email>
</author>
</entry>
<entry gd:etag='W/"C0QBRXrurSp7ImA9WxRVGUo."'>
<id>http://www.example.com/feed/1234.1/posts/full/3067545004648931569</id>
<published>2005-01-07T08:00:00Z</published>
<updated>2005-01-07T08:02:00Z</updated>
<category scheme="http://www.example.com/type" term="blog.post"/>
<title type="text">This is the title of entry 1007</title>
<content type="xhtml">
<div
xmlns="http://www.w3.org/1999/xhtml">This is the entry body of entry 1007</div>
</content>
<link rel="alternate" type="text/html"
href="http://www.example.com/posturl"/>
<link rel="edit" type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full/3067545004648931569"/>
<author>
<name>Elizabeth Bennet</name>
<email>liz@gmail.com</email>
</author>
</entry>
</feed>
요청된 피드가 Atom 형식이고 쿼리 매개변수가 지정되지 않았고 결과에 모든 항목이 포함되지 않은 경우 다음 요소가 최상위 피드에 삽입됩니다. <link rel="next" type="application/atom+xml" href="..."/> 다음 항목 세트가 포함된 피드를 가리킵니다. 후속 세트에는 상응하는 <link rel="previous" type="application/atom+xml" href="..."/> 요소가 포함됩니다. 클라이언트는 모든 다음 링크를 따라 피드에서 모든 항목을 검색할 수 있습니다.
HTTP 상태 코드
다음 표는 Data API의 컨텍스트에서 다양한 HTTP 상태 코드의 의미를 설명합니다.
| 코드 | 설명 |
|---|---|
| 200 확인 | 오류가 없습니다. |
| 201 생성됨 | 리소스를 만들었습니다. |
| 304 수정되지 않음 | 요청의 If-Modified-Since 헤더에 지정된 시간 이후 리소스가 변경되지 않았습니다. |
| 400개의 잘못된 요청 | 잘못된 요청 URI 또는 헤더 또는 지원되지 않는 비표준 매개변수입니다. |
| 401 승인되지 않음 | 인증이 필요합니다. |
| 403 금지됨 | 지원되지 않는 표준 매개변수 또는 인증 또는 승인에 실패했습니다. |
| 404 찾을 수 없음 | 리소스 (예: 피드 또는 항목)를 찾을 수 없습니다. |
| 409 충돌 | 지정된 버전 번호가 리소스의 최신 버전 번호와 일치하지 않습니다. |
| 410명 | 요청된 변경 내역을 서버에서 더 이상 사용할 수 없습니다. 자세한 내용은 서비스별 문서를 참조하세요. |
| 500 내부 서버 오류 | 내부 오류입니다. 인식할 수 없는 모든 서버 오류에 사용되는 기본 코드입니다. |
리소스 버전 관리 (ETag)
경우에 따라 특정 항목의 특정 버전을 참조할 수 있어야 할 수도 있습니다.
이는 특히 다음 두 경우에 중요합니다.
- 클라이언트가 항목을 요청하는 '조건부 검색' 수행. 서버는 클라이언트가 마지막으로 요청한 이후에 변경된 경우에만 항목을 보냅니다.
- 여러 클라이언트가 의도치 않게 서로의 변경사항을 덮어쓰지 않도록 합니다. 클라이언트가 항목의 이전 버전 식별자를 지정하면 Data API가 업데이트와 삭제가 실패하도록 하여 이 작업을 수행합니다.
Google Data API는 HTTP의 표준 부분인 ETag를 사용하여 두 사례를 모두 처리합니다.
ETag는 특정 항목의 특정 버전을 지정하는 식별자입니다. 서버는 클라이언트에 전송하는 ETag를 항목에 입력하고 피드로 연결합니다. 항목 또는 피드가 변경되면 ETag도 변경됩니다.
Google Data API는 ETag HTTP 헤더와 <feed> 및 <entry> 요소의 gd:etag 속성에 ETag를 제공합니다.
Google Data API에서 ETag는 보통 문자와 숫자의 문자열이며 하이픈과 마침표도 포함될 수 있습니다. 문자열은 주로 따옴표로 묶입니다. (따옴표는 ETag의 일부입니다.) 예를 들어 Data API 항목의 ETag는 "S0wCTlpIIip7ImA0X0QI"입니다.
ETag에는 두 가지 유형의 강함과 약함이 있습니다. 강력한 ETag는 특정 항목의 특정 버전을 식별하며, 다른 클라이언트의 변경사항을 덮어쓰지 않도록 하는 데 사용할 수 있습니다. Google Data API와 관련하여 취약한 ETag는 조건부 검색에만 사용됩니다. 약한 ETag는 항상 W/으로 시작합니다. 예를 들면 W/"D08FQn8-eil7ImA9WxZbFEw."입니다.
일부 Google 데이터 API는 강력한 ETag를 지원하지 않습니다. 이 경우 강력한 ETag는 항목에만 사용되며, 피드의 ETag는 항상 취약합니다.
다음은 강력한 ETag를 지원하는 서비스에서 가져온 피드 (일부 HTTP 헤더 포함)의 예입니다.
GData-Version: 2.0
ETag: W/"C0QBRXcycSp7ImA9WxRVFUk."
...
<?xml version='1.0' encoding='utf-8'?>
<feed xmlns='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.google.com/g/2005'
gd:etag='W/"C0QBRXcycSp7ImA9WxRVFUk."'>
...
<entry gd:etag='"CUUEQX47eCp7ImA9WxRVEkQ."'>
...
</entry>
</feed>
데이터 API 버전 2를 지원하는 클라이언트 라이브러리는 ETag를 투명하게 처리합니다. 다음 정보는 클라이언트 라이브러리를 사용하지 않는 클라이언트와 프로토콜 수준에서 버전 관리가 처리되는 방식에 관심이 있는 독자를 대상으로 합니다.
참고: Data API 버전 1.0에서 사용되는 리소스 버전 관리 시스템에 대한 자세한 내용은 1.0 참조 가이드를 확인하세요.
조건부 검색
이전에 검색한 항목을 검색하려는 경우 항목을 마지막으로 검색한 이후 변경된 경우에만 항목을 전송하도록 서버에 지시하여 효율성을 높일 수 있습니다.
이러한 조건부 검색을 수행하려면 HTTP If-None-Match 헤더가 포함된 HTTP GET 요청을 전송합니다. 헤더에서 항목의 ETag를 지정합니다.
다음은 If-None-Match 헤더의 예입니다.
If-None-Match: W/"D08FQn8-eil7ImA9WxZbFEw."
서버는 이 요청을 수신할 때 요청한 항목의 ETag가 지정된 ETag와 같은지 확인합니다. ETag가 일치하면 항목이 변경되지 않고 서버에서 HTTP 304 Not Modified 상태 코드를 반환합니다.
ETag가 일치하지 않으면 마지막으로 요청한 이후로 항목이 수정되고 서버에서 항목을 반환합니다.
항목 업데이트
다른 클라이언트의 변경사항을 덮어쓰지 않도록 하는 가장 쉬운 방법은 클라이언트가 업데이트된 항목을 전송할 때 클라이언트가 시작한 항목의 버전이 서버에 저장된 현재 버전과 동일한지 확인하는 것입니다. 클라이언트가 업데이트되기 전에 두 번째 클라이언트에서 업데이트를 수행하는 경우 클라이언트가 더 이상 최신 버전을 기반으로 하지 않기 때문에 클라이언트의 업데이트가 거부됩니다.
클라이언트가 강력한 ETag를 지원하는 서비스에서 데이터를 가져올 때 각 항목에는 해당 항목 버전의 고유 버전 식별자 역할을 하는 ETag가 있습니다.
참고: ETag를 사용한 업데이트는 강력한 ETag에서만 작동합니다. 취약한 ETag를 제공하는 서비스의 경우, 항목을 받은 이후 다른 사용자가 항목을 업데이트했는지 여부와 관계없이 모든 업데이트가 성공합니다. 최신 업데이트는 다른 이전 업데이트를 항상 덮어씁니다. 따라서 업데이트하거나 삭제할 때 취약한 ETag를 전송하지 마세요. 전송할 경우 오류 메시지가 표시됩니다.
따라서 클라이언트가 강력한 ETag 서비스에 업데이트를 전송할 때는 업데이트할 항목의 버전을 지정해야 합니다. 다음과 같은 두 가지 방법이 있습니다.
If-MatchHTTP 헤더를 사용합니다.<atom:entry>요소에gd:etag속성을 사용합니다.
가능하다면 If-Match 접근 방식을 사용하는 것이 좋습니다.
If-Match를 사용하여 항목을 업데이트하려면 먼저 업데이트할 항목을 획득합니다. 항목을 원하는 대로 변경한 다음 수정된 항목이 포함된 새 PUT 요청을 만듭니다. 사용할 URL에 대한 자세한 내용은 서비스별 문서를 참고하세요.
PUT를 전송하기 전에 원래 항목의 ETag가 포함된 HTTP If-Match 헤더를 추가합니다.
If-Match: "S0wCTlpIIip7ImA0X0QI"
그런 다음 PUT 요청을 보냅니다.
업데이트가 성공하면 서버에서 HTTP 200 OK 상태 코드와 업데이트된 항목의 사본을 반환합니다.
지정한 ETag가 항목의 현재 ETag와 일치하지 않아 (마지막으로 항목을 검색한 후 서버에서 항목이 변경되었음을 의미) 업데이트에 실패하면 서버에서 HTTP 412 Precondition Failed 상태 코드를 반환합니다.
HTTP 헤더를 쉽게 작성할 수 없거나 If-Match 헤더를 사용하지 않아야 할 다른 이유가 있다면 gd:etag 속성을 대신 사용할 수 있습니다.
If-Match 헤더를 전송하지 않으면 서버는 업데이트된 항목의 gd:etag 속성 값을 암시적 If-Match 값으로 사용합니다.
버전 관리 시스템을 재정의하고 검색 이후 다른 사용자가 업데이트했는지 여부와 관계없이 항목을 업데이트하려면 헤더에 ETag를 지정하는 대신 If-Match: *를 사용하세요.
강력한 ETag를 지원하는 서비스에 대한 자세한 내용은 이전 가이드를 참고하세요.
항목 삭제
강력한 ETag를 사용하는 항목을 삭제하는 것은 업데이트와 비슷합니다.
강력한 ETag가 있는 항목을 삭제하려면 먼저 삭제할 항목을 검색한 다음 항목의 수정 URL에 DELETE 요청을 보냅니다.
항목을 검색한 이후 다른 클라이언트에 의해 변경된 항목을 삭제하지 않도록 하려면 원래 항목의 ETag 값이 포함된 HTTP If-Match 헤더를 포함합니다.
버전 관리 시스템을 재정의하고 항목을 검색한 이후 다른 사용자가 항목을 업데이트했는지 여부와 관계없이 항목을 삭제하려면 헤더에 ETag를 지정하는 대신 If-Match: *를 사용하세요.
항목에 강력한 ETag가 없으면 항상 DELETE 요청이 성공합니다.
부분 응답(실험용)
기본적으로 서버는 요청을 처리한 후에 대상 리소스의 전체 표현을 반환합니다. 부분 응답을 사용하면 전체 리소스 표현이 아니라 관심 있는 요소나 속성만 요청할 수 있습니다. 이렇게 하면 클라이언트 애플리케이션에서 불필요한 필드를 전송, 파싱, 저장하지 않으므로 네트워크, CPU, 메모리 리소스를 더 효율적으로 사용할 수 있습니다.
사용 중인 제품에 부분 응답이 제공되는지 확인하려면 API 문서를 참조하세요.
부분 응답을 요청하려면 fields 쿼리 매개변수를 사용하여 반환하려는 요소 또는 속성을 지정합니다. 다음 예를 참고하세요.
http://www.example.com/feeds?fields=link,entry(@gd:etag,id,updated,link[@rel='edit']))
서버의 응답에는 피드의 링크 및 항목 요소만 포함되며 항목 요소에는 ETag, ID, 업데이트된 링크 정보만 포함됩니다. fields 쿼리 매개변수 구문은 다음 섹션에서 다룹니다. 응답에 대한 자세한 내용은 부분 응답 처리를 참고하세요.
참고: fields 쿼리 매개변수는 데이터를 반환하는 모든 요청과 함께 사용할 수 있습니다. 여기에는 GET 외에 POST, PUT(부분 업데이트에 사용되는 PATCH)도 포함됩니다. 하지만 fields 쿼리 매개변수는 응답 데이터에만 영향을 주며 제공해야 하는 데이터나 업데이트 또는 생성되는 필드에는 영향을 미치지 않습니다.
fields 매개변수 구문 요약
fields 쿼리 매개변수 값의 형식은 XPath 구문에 기반하지만 유효한 XPath 표현식의 하위 집합만 지원합니다. 지원되는 구문은 아래에 요약되어 있으며 이어지는 섹션에서 추가적인 예시를 확인할 수 있습니다.
- 여러 필드를 선택하려면 쉼표로 구분된 목록을 사용합니다.
a/b를 사용하여a요소 내에 중첩된b요소를 선택하고a/b/c을 사용하여b내에 중첩된 요소c을(를) 선택하세요.'@'접두사를 사용하여 지정된 이름의 속성을 식별합니다. 요소를 참조하려면'@'접두사를 생략합니다.- 제한하려는 요소 뒤에 '
[ ]' 괄호 안에 표현식을 배치하여 특정 조건을 충족하는 요소를 선택하려면 필드 조건을 적용합니다.예를 들어
fields=entry[author/name='Elizabeth']는 엘리자베스가 저자인 피드 항목만 반환합니다. - 선택한 요소 뒤에 괄호 '
( )'를 넣으면 특정 속성 또는 하위 요소만 요청하도록 필드 하위 선택기를 지정할 수 있습니다.예를 들어
fields=entry(id,author/email)은 각 피드 항목의 ID와 작성자 이메일만 반환합니다. - 큰따옴표 또는 작은따옴표
를 사용하여 문자열을 구분할 수 있습니다.
큰따옴표나 작은따옴표를 이스케이프 처리하려면 인용을 반복합니다. 예를 들어"""Hello,"" he said"는 문자열"Hello," he said을 생성하고'''Hello,'' he said'는 문자열'Hello,' he said를 생성합니다. - 필드 선택에 와일드 카드를 사용할 수 있습니다.
예를 들어
entry/gd:*는gd네임스페이스에서 항목의 모든 하위 요소를 선택하고entry/@gd:*는 동일한 네임스페이스에서 하위 요소 속성을 선택합니다.
fields 쿼리 매개변수는 출력 필터 역할을 합니다. 즉, 부분 응답은 쿼리의 나머지 부분을 처리한 후에만 계산됩니다. 예를 들어 max-results 쿼리 매개변수도 지정하여 페이지당 20개의 결과를 원한다고 표시하면 처음 20개의 결과가 생성되고 이 결과에서 부분 응답이 계산됩니다. fields 사양이 쿼리에서 선택한 처음 20개 항목과 일치하지 않으면 빈 피드를 반환합니다. 일치하는 처음 20개 항목은 반환하지 않습니다.
참고: 쿼리 선택기로 필드 조건을 사용하지 마세요. 즉, 전체 피드를 검색하고 필드 조건을 적용하여 매우 큰 데이터 세트에서 관심 있는 항목을 필터링하려고 해서는 안 됩니다. 가능하면 다른 쿼리 매개변수(예: start-index, max-results)를 사용하여 각 쿼리의 결과를 관리 가능한 크기로 줄이세요. 그러지 않으면 잘못된 사용으로 인한 심각한 성능 저하로 인해 부분 응답으로 인한 성능 향상 효과를 상회할 수 있습니다.
필드 매개변수 값 형식 지정
다음 가이드라인에서는 fields 쿼리 매개변수 값을 구성하는 방법을 설명합니다. 각 가이드라인에는 예시가 포함되어 있으며 매개변수 값이 응답에 미치는 영향을 설명합니다.
참고: 모든 쿼리 매개변수 값과 마찬가지로 fields 매개변수 값도 URL로 인코딩되어야 합니다. 가독성을 높이기 위해 아래 예시에서는 인코딩을 생략했습니다.
- 반환받을 필드 지정(또는 필드 선택)
fields쿼리 매개변수 값은 쉼표로 구분된 요소 또는 속성 목록 (통칭하여 필드)이며 각 필드는 리소스 표현의 루트 요소를 기준으로 지정됩니다. 따라서 피드를 검색할 경우 필드가<feed>요소를 기준으로 지정되며 단일 항목을 검색할 경우<entry>요소를 기준으로 필드가 지정됩니다. 선택한 요소가 피드에서 반복되는 요소이거나 이러한 요소의 일부인 경우 서비스는 이 요소의 모든 인스턴스를 반환합니다.
다음은 피드 수준의 예입니다.
예 결과 entry모든 <entry>요소 및 이러한 항목의 모든 하위 요소를 반환하지만<feed>의 다른 하위 요소는 반환하지 않습니다.id,entry피드 <id>및 모든<entry>요소를 모두 반환합니다.entry/title모든 피드 항목의 <title>요소를 반환합니다.
중첩된 요소가 반환될 때마다 응답에는상위 요소의 포함 태그가 포함됩니다. 명시적으로 선택하지 않으면 상위 태그에는 다른 하위 요소나 속성이 포함되지 않습니다.entry/author/uri모든 피드 항목에 대해 <author>요소의<uri>하위 요소만 반환합니다.entry/*:rating모든 피드 항목의 네임스페이스에서 로컬 이름이 rating인 하위 요소만 반환합니다.
다음은 초급 수준의 예시입니다.
예 결과 author타겟 항목의 <author>하위 요소를 반환합니다.@gd:etag타겟 항목의 etag속성을 반환합니다.author/uri타겟 항목에 대해 <author>요소의<uri>하위 요소를 반환합니다.media:group/media:*대상 항목의 media네임스페이스에서<media:group>의 모든 하위 필드를 반환합니다.- 특정 기준과 일치하는 선택된 필드로 응답을 제한하거나 필드 조건을 사용하세요.
- 기본적으로 요청에서 2회 이상 발생하는 요소를 지정하면 부분 응답에 해당 요소의 모든 인스턴스가 포함됩니다. 그러나 아래 예와 같이 특정 속성 값이 있는 요소나 '
[ ]' 구문을 사용하여 다른 조건을 충족하는 요소만 응답에 포함하도록 지정할 수도 있습니다. 자세한 내용은 필드 조건 구문 섹션을 참조하세요.예 결과 entry[link/@rel='edit']rel속성 값이'edit'인<link>요소가 포함된 모든 피드 항목을 반환합니다.entry/title[text()='Today']콘텐츠가 'Today'인 경우 피드 항목에서 발생하는<title>요소를 반환합니다.entry/author[name='Jo']콘텐츠에 'Jo'콘텐츠가 있는<name>하위 요소가 있으면 피드 항목에서 발생하는 모든<author>요소를 반환합니다.author[name='Jo']'Jo'콘텐츠가 있는<name>하위 요소가 있으면 타겟 항목의<author>요소를 반환합니다. - 선택한 요소의 일부만 요청하거나 하위 필드 선택을 사용하세요.
- 기본적으로 요청에서 특정 요소를 지정하면 서비스가 요소 전체를 반환합니다. 응답에 선택한 요소 내의 특정 하위 요소만 포함되도록 지정할 수 있습니다. 아래 예와 같이 '
( )' 하위 선택 구문을 사용하면 됩니다.예 결과 entry/author(uri)피드 항목의 작성자에 대해 <uri>하위 요소만 반환합니다.entry/author[name='Jo'](uri)작성자 이름이 'Jo'인 모든 항목에 대해<author>의<uri>하위 요소만 반환합니다.entry(link(@rel,@href))피드 항목의 각 <link>요소에 대한rel및href속성의 값만 반환합니다.entry(title,link[@rel='edit'])각 피드 항목의 rel수정 속성이 있는<title>및<link>요소만 반환합니다.entry(title,author(uri)각 피드 항목에 <title>요소와 작성자<uri>요소를 모두 반환합니다.
필드 조건 구문 자세히 알아보기
필드 또는 필드로 필드 조건을 사용할 수 있습니다. 선택한 필드가 결과에 포함되려면 조건이 true로 평가되어야 합니다.필드 조건이 없으면 선택한 유형의 모든 필드가 포함됩니다.
선택한 필드의 텍스트 값이 비교에 사용됩니다. 이 맥락에서 필드가 요소인 경우 텍스트 값은 그 콘텐츠입니다. 필드가 속성인 경우 텍스트 값은 속성의 값입니다. 필드에 텍스트 값이 없으면 비교가 실패하고 필드가 결과에 포함되지 않습니다.
다음 표에서는 필드 조건에 지원되는 XPath 연산자를 보여주며 몇 가지 예를 제공합니다.
| 연산자 | 문법 | 예 |
|---|---|---|
| 문자열 비교 |
|
|
| 논리적 비교 | and |
|
| 숫자 비교 | = 또는 eq!= 또는 ne> 또는 gt>= 또는 ge< 또는 lt<= 또는 le
|
|
| 날짜 비교 | 예와 같이 숫자 비교 연산자를 사용합니다. | 날짜 또는 날짜/시간 비교를 위해 요소, 속성 또는 문자열 리터럴을
|
| 존재 | 예에 표시된 대로 요소 또는 속성의 이름을 사용합니다. |
|
| Boolean | true()false()
|
불리언은 테스트 중에 필드 조건을 강제로 true 또는 false 상태로 만드는 데 유용합니다.
|
부분 응답 처리
부분 응답을 지원하는 서버는 fields 쿼리 매개변수가 포함된 유효한 요청을 처리한 후 요청된 속성 또는 요소와 함께 HTTP 200 OK 상태 코드를 반환합니다. fields 쿼리 매개변수에 오류가 있거나 유효하지 않은 경우 서버는 HTTP 400 Bad Request 상태 코드를 반환합니다.
응답의 루트 요소는 대상 URI에 따라 <feed> 또는 <entry>입니다. 루트 요소의 콘텐츠에는 피드 또는 항목에 대해 선택한 입력란과 모든 상위 요소에 대한 인클로징 태그가 포함됩니다.
요청의 fields 쿼리 매개변수 값을 다음 두 가지 방법으로 에코할 수 있습니다.
- 루트 요소에는 요청에 지정된
fields쿼리 매개변수의 값을 보여주는gd:fields속성이 있습니다. - 타겟 URI가 피드인 경우 수정 가능한 각 항목에는 해당 항목에 적용되는
fields선택 부분을 보여주는gd:fields속성이 있습니다.
참고: 부분 응답에서 이러한 gd:fields 속성 값을 보려면 fields 쿼리 매개변수 사양에 포함해야 합니다. @gd:fields를 사용하거나 ETag 정보도 포함된 더 일반적인 @gd:*를 사용하여 명시적으로 실행할 수 있습니다.
다음 쿼리 예시는 서버에 각 피드 항목의 피드 ID, 제목, 수정 링크와 함께 gd 네임스페이스의 속성 (피드와 항목 수준 모두)만 포함된 문서를 반환하도록 요청합니다.
http://example.com/myFeed?fields=@gd:*,id,entry(@gd:*,title,link[@rel='edit'])
서버는 200 Successful HTTP 상태 코드와 함께 다음과 같은 부분 응답을 반환합니다.
<?xml version='1.0' encoding='utf-8'?>
<feed xmlns='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.google.com/g/2005'
gd:etag='W/"DEAEQH47eCp7IWA9WxBVGUo."'
gd:fields='@gd:*,id,entry(@gd:*,title,link[@rel='edit'])>
<id>http://example.com/myFeed</id>
<entry gd:etag='"EksPTg1Bfyp7IWA6WhJT"'
gd:fields="@gd:*,title,link[@rel='edit']">
<link rel='edit' href='http://example.com/myFeed/1/'/>
<title>This year</title>
</entry>
<entry gd:etag='"EksPQA1Cdyp7IWA6WhJT"'
gd:fields="@gd:*,title,link[@rel='edit']">
<link rel='edit' href='http://example.com/myFeed/2/'/>
<title>Last year</title>
</entry>
<entry d:etag='"EksPQAxHeCp7IWA6WhJT"'
gd:fields="@gd:*,title,link[@rel='edit']">
<link rel='edit' href='http://example.com/myFeed/3/'/>
<title>Today</title>
</entry>
</feed>
선택한 필드가 아무것도 일치하지 않으면 서비스는 여전히 200 Successful HTTP 상태 코드를 반환하지만 부분 응답은 빈 피드입니다.
<?xml version='1.0' encoding='utf-8'?> <feed xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google.com/g/2005' gd:etag='W/"DEAEQH47eCp7IWA9WxBVGUo."' gd:fields='@gd:*,id,entry(@gd:*,title,link[@rel='edit'])> </feed>
부분 업데이트(실험용)
부분 응답 및 수정 가능한 리소스를 지원하는 Google 제품에서도 부분 업데이트를 사용할 수 있습니다. 부분 업데이트에서는 전체 리소스 표현의 수정된 버전을 전송하는 대신, 업데이트하려는 필드만 전송합니다. 이렇게 하면 클라이언트 애플리케이션은 업데이트할 때와 부분 응답을 사용하여 데이터를 검색할 때 더 효율적입니다.
그러나 PUT를 사용하는 대신 부분 업데이트 시 PATCH 요청을 사용해야 합니다. PATCH의 시맨틱스는 단일 요청으로 특정 항목의 특정 필드를 추가, 교체, 삭제할 수 있을 만큼 강력합니다.
사용 중인 제품에 부분 업데이트가 있는지 알아보려면 제품별 문서를 참고하세요.
부분 업데이트 요청 제출
부분 업데이트 요청을 제출하려면 일반적으로 PUT를 사용하여 리소스를 업데이트하는 동일한 URL에 HTTP PATCH 요청을 전송합니다. PATCH 요청의 본문은 추가하거나 수정할 필드를 지정하는 부분적인 <entry> 요소입니다. 항목의 gd:fields 속성은 삭제할 필드를 나타냅니다.
서버는 PATCH 요청을 특정 순서로 처리합니다.
- 먼저 리소스 속성에서
gd:fields속성으로 지정된 필드를 삭제합니다.gd:fields속성의 문법은 부분 응답을 요청할 때 사용되는fields쿼리 매개변수의 구문과 동일합니다. 자세한 내용은 지원되는 구문을 참고하세요. - 그런 다음 요청 본문에 제공된 데이터를 기존 리소스 표현과 병합합니다.
데이터 병합 방법에 대한 자세한 내용은 아래 필드 추가 또는 업데이트를 참고하세요.
참고: PATCH 요청의 본문은 일반적으로 Atom 신디케이션 형식을 준수하지 않으므로 PATCH 요청에 사용하는 Content-Type는 application/xml입니다.
다음은 부분 업데이트 요청의 예입니다.
PATCH /myFeed/1/1/
Content-Type: application/xml
<entry xmlns='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.google.com/g/2005'
gd:fields='description'>
<title>New title</title>
</entry>
이 PATCH 요청은 대상 URI 항목의 서버에 저장된 리소스 표현을 다음과 같이 변경합니다.
<description>요소를 삭제합니다.<title>요소를 업데이트합니다.
부분 업데이트 요청의 의미 체계
아래 안내에서는 PATCH 요청을 설정하여 항목 내 특정 필드를 삭제, 추가 또는 업데이트하는 방법을 설명합니다. 단일 PATCH 요청은 이러한 연산의 조합을 수행할 수 있습니다.
필드 삭제.
<entry>요소의gd:fields속성을 사용하여 리소스에서 삭제할 필드를 식별합니다. 다음 샘플 요청은 항목과 연결된 제목과 요약을 삭제합니다. 하지만 요청은 항목에 대한 다른 데이터를 추가하거나 업데이트하지 않습니다.PATCH /myfeed/1/1/ Content-Type: application/xml <entry xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google.com/g/2005' gd:fields='title,summary'/>필드 추가 또는 업데이트.
<entry>요소의 본문을 사용하여 리소스에 추가하거나 업데이트하려는 데이터를 지정합니다. 이러한 필드는 다음 규칙에 따라 삭제된 후 리소스의 기존 데이터에 병합됩니다.아직 존재하지 않는 필드가 추가됩니다. 리소스 데이터에 아직 필드 값이 지정되지 않은 경우 필드가 기존 데이터에 추가됩니다. 예를 들어 항목에 제목이 없고
PATCH요청에<title>요소가 있으면 새 제목이 항목에 추가됩니다.이미 있는 필드가 교체되거나 추가됩니다. 리소스 데이터에 이미 지정된 필드를 병합하는 특정 동작은 필드의 특성에 따라 다릅니다.
반복되지 않는 입력란이 대체됩니다. 리소스 데이터에서 반복되지 않는 요소의 값을 이미 지정한 경우
PATCH요청에 지정한 값이 해당 요소의 기존 값을 대체합니다. 예를 들어 아래 예에서 기존 제목이 새 제목으로 대체됩니다.PATCH /myFeed/1/1/ Content-Type: application/xml <entry xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google.com/g/2005'> <title>New Title</title> </entry>아래는 좀 더 복잡한 예입니다. 이 예에서는 항목에 작성자가 하나만 있을 수 있고 대상 리소스에 이미 작성자의 이름과 이메일 주소 값이 있다고 가정합니다.
<author>요소에 하위 필드가 두 개 있지만 제공된 데이터에는<name>요소만 있습니다. 따라서 해당 필드의 값만 덮어써집니다. 제공된 데이터에서 누락된<email>요소의 값은 변경되지 않습니다.PATCH /myfeed/1/1/ Content-Type: application/xml <entry xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google.com/g/2005'> <author> <name>New Name</name> </author> </entry>반복되는 필드가 추가됩니다. 리소스 데이터가 이미 반복 요소의 값을 지정한 경우 새로 입력한 요소가 기존 값 세트에 추가됩니다.
반복되는 요소의 새 인스턴스를 추가하는 것 외에 다른 작업을 해야 할 때가 있습니다. 예를 들어 다음 중 하나를 수행할 수 있습니다.
반복 요소의 전체 목록을 바꿉니다.
gd:fields속성 (예:gd:fields='ns:accessControl')을 사용하여 모든 반복 필드를 삭제하고 대체 필드 전체를 제공할 수 있습니다. 모든 기존 요소가 먼저 삭제되므로 제공된 필드 세트는 추가될 때 기존 값과 충돌하지 않습니다.반복 요소의 기존 값 집합에서 하나의 값을 바꿉니다. 이 경우 유지하려는 다른 값이 삭제되지 않도록
gd:fields값을 충분히 좁은 범위로 정의하면 단일 요소가 삭제됩니다. 예를 들어action가embed인 액세스 제어만 삭제하려면gd:fields='ns:accessControl[@action="embed"]'를 사용할 수 있습니다. 그런 다음 대체하려는 단일 필드를<entry>요소의 본문에 입력합니다.PATCH /myfeed/1/1/ Content-Type: application/xml <entry xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google.com/g/2005' gd:fields='ns:accessControl[@action="embed"]> <ns:accessControl action="embed" permission="allowed" /> </entry>
부분 업데이트에 대한 응답 처리
유효한 부분 업데이트 요청을 처리한 후 API는 200 OK HTTP 응답 코드를 반환합니다. 기본적으로 응답 본문은 업데이트한 전체 항목입니다. 서버는 PUT에서와 마찬가지로 PATCH 요청을 성공적으로 처리할 때 ETag 값을 업데이트합니다.
PATCH 요청으로 인해 새 리소스 상태의 구문 또는 의미 체계가 올바르지 않게 되면 서버에서 HTTP 400 Bad Request 또는 422 Unprocessable Entity HTTP 상태 코드를 반환하고 리소스 상태는 변경되지 않습니다. 예를 들어 필수 필드를 삭제하려고 하는데 대체 항목을 제공하지 않으면 서버에서 오류를 반환합니다.
참고: 여러 필드의 상관관계를 파악하는 것이 중요합니다. 상호 상호 의존적인 값의 일부만 업데이트하여 리소스를 일관되지 않은 상태로 만들 수 있습니다. 예를 들어 시작 시간을 종료 시간보다 이후 값으로 업데이트할 수 있습니다. API가 오류 코드를 반환해야 하지만 이러한 종류의 조건을 완전히 테스트하여 일관성을 유지하는 것이 좋습니다.
PATCH가 지원되지 않는 경우 대체 표기법
방화벽이 PATCH를 허용하지 않는 경우 아래와 같이 HTTP POST 요청을 실행하고 재정의 헤더를 PATCH로 설정합니다.
POST /myfeed/1/1/ X-HTTP-Method-Override: PATCH Content-Type: application/xml ...
부분 업데이트로 부분 응답 사용
부분 응답을 후속 부분 업데이트 요청의 기본으로 사용할 수 있습니다. 이렇게 하면 수정 링크가 포함된 fields 쿼리 매개변수와 @gd:*를 지정합니다. 이렇게 하면 부분 응답에 후속 요청에 중요한 ETag 및 gd:fields 속성 값과 같은 정보가 포함됩니다.
다음은 향후 부분 업데이트의 기반으로 사용할 수 있는 부분 응답을 반환하는 예입니다.
http://example.com/myFeed/1/1/?fields=@gd:*,link[@rel='edit'](@href),gd:who
서버가 다음과 같이 응답합니다.
<?xml version='1.0' encoding='utf-8'?>
<entry xmlns='http://www.w3.org/2005/Atom'
xmlns:gd='http://schemas.google.com/g/2005'
gd:etag='"E0UKRAREeCp7IWA6WhJT"'
gd:fields="@gd;*,link[@rel='edit'](@href),gd:who">
<link href='http://example.com/myFeed/1/1/'/>
<gd:who email='liz@gmail.com'/>
<gd:who email='jo@gmail.com'/>
<gd:who email='jane@gmail.com'/>
</entry>
이메일 주소가 'jane@gmail.com'인 사용자를 삭제하고, 이메일이 'will@gmail.com'인 사용자를 추가한 다음, 현재 'jo@gmail.com'으로 등록된 사용자의 이메일을 'josy@gmail.com'로 변경한다고 가정해 보겠습니다.
이렇게 하려면 이전 응답의 결과로 시작하여 다른 필드만 수정한 후 수정된 부분 항목을 PATCH 요청의 본문으로 제출하면 됩니다. 이 예에서 필요한 수정사항은 다음과 같습니다.
- 제공된 요소 목록에서
<gd:who email='jane'/>를 삭제합니다. - 제공된 요소 목록에
<gd:who email='will@gmail.com'/>를 추가합니다. <gd:who email='jo@gmail.com'/>를<gd:who email='josy@gmail.com'/>로 바꿉니다.
다음은 중요한 부분 응답에 기반한 PATCH 요청입니다.
PATCH /myFeed/1/1/
Content-Type: application/xml
<entry gd:fields="@gd:*,link[@rel='edit'](@href),gd:who"
gd:etag="FE8LQQJJeSp7IWA6WhVa">
<link href='http://example.com/myFeed/1/1'/>
<gd:who email='liz@gmail.com'/>
<gd:who email='josy@gmail.com'/>
<gd:who email='will@gmail.com'/>
</entry>
참고: 이 접근 방식은 항목의 부분 응답에 포함된 gd:fields 및 gd:etag (지원되는 경우) 속성을 사용합니다. 부분 항목의 본문은 명시적으로 삭제하려는 항목을 제외하고 부분 응답에 있던 모든 필드와 속성을 유지해야 합니다. 본문에 있는 기존 필드를 새 값으로 업데이트할 수 있으며, 추가하려는 새 필드를 포함할 수 있습니다.
인증
클라이언트가 서비스에 액세스하려고 할 때 서비스에 사용자의 사용자 인증 정보를 제공하여 사용자에게 해당 작업을 실행할 권한이 있음을 증명해야 합니다.
클라이언트가 인증에 사용해야 하는 접근 방식은 클라이언트 유형에 따라 다릅니다.
- 데스크톱 애플리케이션은 설치된 애플리케이션에 대한 계정 인증('ClientLogin'이라고도 함)이라는 Google 전용 인증 시스템을 사용해야 합니다. (웹 기반 클라이언트는 이 시스템을 사용해서는 안 됩니다.)
- Google 서비스의 타사 프런트엔드와 같은 웹 기반 클라이언트는 웹 기반 애플리케이션용 계정 인증 프록시('AuthSub'라고도 함)라는 Google 전용 인증 시스템을 사용해야 합니다.
ClientLogin 시스템에서 데스크톱 클라이언트는 사용자에게 사용자 인증 정보를 요청한 다음 해당 사용자 인증 정보를 Google 인증 시스템으로 전송합니다.
인증에 성공하면 인증 시스템은 클라이언트가 Data API 요청을 보낼 때 HTTP 승인 헤더에 사용하는 토큰을 반환합니다.
인증에 실패하면 서버에서 403 Forbidden 상태 코드와 함께 인증에 적용할 수 있는 본인 확인 요청을 포함하는 WWW-Authenticate 헤더를 반환합니다.
AuthSub 시스템은 이와 비슷하게 작동하지만, 사용자에게 사용자 인증 정보를 요청하는 대신 사용자 인증 정보를 요청하는 Google 서비스에 사용자를 연결한다는 점이 다릅니다. 그런 다음 서비스는 웹 애플리케이션에서 사용할 수 있는 토큰을 반환합니다. 이 접근 방법의 장점은 웹 프런트엔드가 아닌 Google에서 사용자의 사용자 인증 정보를 안전하게 처리하고 저장한다는 것입니다.
이러한 인증 시스템에 관한 자세한 내용은 Google Data API 인증 개요 또는 Google 계정 인증 문서를 참고하세요.
세션 상태
많은 비즈니스 로직 구현 시 세션 유지, 사용자 세션의 상태 추적이 필요합니다.
Google에서는 두 가지 방법으로 세션 상태를 추적합니다. 하나는 쿠키를 사용하고, 다른 하나는 쿼리 매개변수로 전송할 수 있는 토큰을 사용하는 것입니다. 두 방법 모두 동일한 효과를 냅니다. 클라이언트는 다음 세션 상태 추적 방법 중 하나를 지원하는 것이 좋습니다 (둘 중 한 가지로 충분함). 이러한 메서드를 지원하지 않는 클라이언트도 데이터 API를 사용할 수는 있지만, 이러한 메서드를 지원하는 클라이언트에 비해 성능이 저하될 수 있습니다. 특히 클라이언트가 이러한 메서드를 지원하지 않으면 모든 요청이 리디렉션되므로 모든 요청 (및 관련 데이터)이 두 번 서버로 전송되어 클라이언트와 서버의 성능에 영향을 미칩니다.
Google 클라이언트 라이브러리는 세션 상태를 처리하므로 Google의 라이브러리를 사용하면 세션 상태 지원을 받기 위해 별도의 조치를 취할 필요가 없습니다.
추가 리소스
다음과 같은 타사 문서가 유용할 수 있습니다.
- Atom과 RSS의 비교
- IBM Atom 개요
- RSS에 대한 더블린 코어 확장 프로그램
- HTTP 1.1 메서드 정의:
GET,POST,PUT,DELETE사양 - HTTP 1.1 상태 코드 정의
- REST 프로토콜을 만드는 방법
- REST 방식으로 웹 서비스 빌드하기
- XML의 기술 소개
- XML 네임스페이스 예
- HTTP 사양의 ETag 섹션