승인
Google 포토 라이브러리 API에 대한 모든 요청은 인증된 사용자의 승인을 받아야 합니다.
OAuth 2.0의 자세한 승인 프로세스는 개발 중인 애플리케이션의 종류에 따라 약간 다릅니다. 모든 애플리케이션 유형에는 다음과 같은 일반적인 프로세스가 적용됩니다.
- 다음을 수행하여 승인 프로세스를 준비합니다.
- Google API 콘솔을 사용하여 애플리케이션을 등록합니다.
- 라이브러리 API를 활성화하고 클라이언트 ID 및 클라이언트 보안 비밀번호와 같은 OAuth 세부정보를 검색합니다. 자세한 내용은 시작하기를 참고하세요.
- 사용자 데이터에 액세스하기 위해 애플리케이션은 Google에 특정 액세스 범위를 요청합니다.
- Google은 사용자에게 애플리케이션이 일부 데이터를 요청할 수 있도록 승인할지 묻는 동의 화면을 표시합니다.
- 사용자가 승인하면 Google은 잠시 후에 만료되는 액세스 토큰을 애플리케이션에 제공합니다.
- 애플리케이션이 사용자 데이터를 요청하고 액세스 토큰을 요청에 첨부합니다.
- Google에서는 요청과 토큰이 유효하다고 판단하면 요청된 데이터를 반환합니다.
애플리케이션에 적합한 범위를 확인하려면 승인 범위를 참고하세요.
일부 애플리케이션 유형의 프로세스에는 갱신 토큰을 사용하여 새 액세스 토큰을 가져오는 등의 추가 단계가 포함됩니다. 다양한 유형의 애플리케이션 흐름에 관한 자세한 내용은 OAuth 2.0을 사용하여 Google API에 액세스를 참고하세요.
캐싱
데이터를 최신 상태로 유지합니다.
성능상의 이유로 미디어 (썸네일, 사진, 동영상)를 일시적으로 저장해야 하는 경우 사용 가이드라인에 따라 60분 넘게 캐시하지 마세요.
또한 약 60분 후에 만료되는 baseUrls도 저장하지 않아야 합니다.
사용자 라이브러리의 콘텐츠를 고유하게 식별하는 미디어 항목 ID와 앨범 ID는 캐싱 제한에서 제외됩니다. 이러한 ID는 애플리케이션의 개인정보처리방침에 따라 무기한으로 저장할 수 있습니다. 적절한 엔드포인트를 사용하여 액세스 가능한 URL과 데이터를 다시 검색하려면 미디어 항목 ID와 앨범 ID를 사용하세요. 자세한 내용은 미디어 항목 가져오기 또는 앨범 나열을 참고하세요.
새로고침할 미디어 항목이 많으면 미디어 항목을 반환한 검색 매개변수를 저장하고 쿼리를 다시 제출하여 데이터를 다시 로드하는 것이 더 효율적일 수 있습니다.
SSL 액세스
HTTPS는 다음 URL을 사용하는 모든 라이브러리 API 웹 서비스 요청에 필요합니다.
https://photoslibrary.googleapis.com/v1/service/output?parameters
HTTP를 통한 요청은 거부됩니다.
오류 처리
API에서 반환된 오류를 처리하는 방법에 대한 자세한 내용은 Cloud API 오류 처리를 참조하세요.
실패한 요청 재시도
클라이언트는 지수 백오프에 설명된 대로 지수 백오프로 5xx 오류 발생 시 재시도해야 합니다. 최소 지연은 달리 문서화되지 않는 한 1 s이어야 합니다.
429 오류의 경우 클라이언트는 최소 30s 지연으로 재시도할 수 있습니다. 다른 모든 오류의 경우 재시도가 적용되지 않을 수 있습니다. 요청이 멱등성을 갖는지 확인하고 오류 메시지를 참조하여 안내를 받으세요.
지수 백오프
드물지만 요청을 처리하는 중에 문제가 발생할 수 있습니다.4XX 또는 5XX HTTP 응답 코드가 수신되거나 클라이언트와 Google 서버 간 TCP 연결이 실패할 수 있습니다. 요청을 다시 시도하는 것이 좋습니다. 기존 요청이 실패하면 후속 요청도 성공할 수 있습니다. 하지만 Google 서버에 반복적으로 요청을 보내 루프를 하지 않는 것이 중요합니다. 이러한 반복 동작으로 클라이언트와 Google 사이에 네트워크에 과부하가 발생하여 많은 경우 문제가 발생할 수 있습니다.
따라서 시도 사이의 지연 시간을 늘려 재시도하는 것이 훨씬 좋습니다. 일반적으로 지연 시간은 시도할 때마다 곱셈 배수로 증가하며, 이러한 접근 방식을 지수 백오프라고 합니다.
또한 빠른 연달아 반복된 요청으로 이어지는 애플리케이션 호출 체인의 높은 재시도 코드가 없도록 주의해야 합니다.
Google API의 적절한 사용
잘못 설계된 API 클라이언트는 인터넷과 Google 서버 모두에 필요 이상으로 많은 부하를 발생시킬 수 있습니다. 이 섹션에는 API 클라이언트를 위한 몇 가지 권장사항이 포함되어 있습니다. 이러한 권장사항을 따르면 의도치 않은 API 악용으로 애플리케이션이 차단되는 것을 방지할 수 있습니다.
동기화된 요청
Google API에 대해 동기화된 다수의 요청은 Google 인프라에 대한 분산 서비스 거부 (DDoS) 공격으로 보일 수 있으므로 적절하게 처리됩니다. 이를 방지하려면 API 요청이 클라이언트 간에 동기화되지 않도록 해야 합니다.
예를 들어 현재 시간대의 시간을 표시하는 애플리케이션을 생각해 보세요. 이 애플리케이션은 표시된 시간을 업데이트할 수 있도록 클라이언트 운영체제에 분 시작 시점에 절전 모드를 해제하는 알람을 설정할 가능성이 높습니다. 애플리케이션은 알람과 관련된 처리의 일부로 API를 호출해서는 안 됩니다.
고정된 알람에 대한 응답으로 API를 호출하면 좋지 않습니다. 시간이 지남에 따라 고르게 분산되지 않고 서로 다른 기기 사이에서도 API 호출이 분 시작 시점에 동기화되기 때문입니다. 잘못 설계된 애플리케이션은 매분 시작할 때 정상 수준의 60배에 달하는 트래픽이 급증합니다.
대신 한 가지 좋은 설계는 두 번째 알람을 무작위로 선택한 시간으로 설정하는 것입니다. 이 두 번째 알람이 실행되면 애플리케이션은 필요한 API를 호출하고 결과를 저장합니다. 분 시작 시 디스플레이를 업데이트하기 위해 애플리케이션은 API를 다시 호출하는 대신 이전에 저장된 결과를 사용합니다. 이 방법을 사용하면 API 호출이 시간이 지남에 따라 고르게 분산됩니다. 또한 API 호출은 디스플레이가 업데이트될 때 렌더링을 지연시키지 않습니다.
분 시작 시간을 제외하고 타겟팅하지 않도록 주의해야 하는 다른 일반적인 동기화 시간은 1시간의 시작 시점과 매일 자정에 시작됩니다.