Praktik terbaik

Otorisasi

Semua permintaan ke Google Photos Library API harus diizinkan oleh pengguna yang diautentikasi.

Detail proses otorisasi untuk OAuth 2.0 sedikit berbeda bergantung pada jenis aplikasi yang Anda tulis. Proses umum berikut berlaku untuk semua jenis aplikasi:

  1. Persiapkan proses otorisasi dengan melakukan hal berikut:
    • Daftarkan aplikasi Anda menggunakan Konsol API Google.
    • Aktifkan Library API dan ambil detail OAuth, seperti client ID dan rahasia klien. Untuk mengetahui informasi selengkapnya, lihat Memulai.
  2. Untuk mengakses data pengguna, aplikasi membuat permintaan ke Google untuk cakupan akses tertentu.
  3. Google menampilkan layar izin kepada pengguna yang meminta mereka mengizinkan aplikasi untuk meminta beberapa data mereka.
  4. Jika pengguna menyetujui, Google akan memberi aplikasi token akses yang akan habis masa berlakunya setelah beberapa saat.
  5. Aplikasi membuat permintaan untuk data pengguna, dengan melampirkan token akses ke permintaan tersebut.
  6. Jika Google menentukan bahwa permintaan dan token valid, data yang diminta akan ditampilkan.

Untuk menentukan cakupan yang cocok untuk aplikasi Anda, lihat Cakupan otorisasi.

Proses untuk beberapa jenis aplikasi mencakup langkah-langkah tambahan, seperti menggunakan token refresh untuk memperoleh token akses baru. Guna mengetahui informasi mendetail tentang alur untuk berbagai jenis aplikasi, lihat Menggunakan OAuth 2.0 untuk Mengakses Google API.

Menyimpan ke cache

Selalu perbarui data.

Jika Anda perlu menyimpan media untuk sementara (seperti thumbnail, foto, atau video) untuk alasan performa, jangan meng-cache-nya lebih dari 60 menit sesuai panduan penggunaan kami.

Anda juga tidak boleh menyimpan baseUrls, yang masa berlakunya akan habis setelah sekitar 60 menit.

ID item media dan ID album yang secara unik mengidentifikasi konten dalam library pengguna dikecualikan dari pembatasan penyimpanan cache. Anda dapat menyimpan ID ini tanpa batas waktu (tunduk pada kebijakan privasi aplikasi Anda). Gunakan ID item media dan ID album untuk mengambil kembali data dan URL yang dapat diakses menggunakan endpoint yang sesuai. Untuk mengetahui informasi selengkapnya, lihat Mendapatkan item media atau Mencantumkan album.

Jika Anda memiliki banyak item media untuk dimuat ulang, mungkin akan lebih efisien untuk menyimpan parameter penelusuran yang menampilkan item media tersebut dan mengirim ulang kueri untuk memuat ulang data.

Akses SSL

HTTPS diperlukan untuk semua permintaan layanan web Library API yang menggunakan URL berikut:

https://photoslibrary.googleapis.com/v1/service/output?parameters

Permintaan yang dibuat melalui HTTP akan ditolak.

Penanganan error

Untuk mengetahui informasi tentang cara menangani error yang ditampilkan dari API, lihat Menangani error pada Cloud API.

Mencoba lagi permintaan yang gagal

Klien harus mencoba lagi pada error 5xx dengan backoff eksponensial seperti yang dijelaskan dalam Backoff eksponensial. Penundaan minimum harus 1 s kecuali jika didokumentasikan lain.

Untuk error 429, klien dapat mencoba lagi dengan penundaan minimum 30s. Untuk semua error lainnya, percobaan ulang mungkin tidak berlaku. Pastikan permintaan Anda bersifat idempoten dan lihat pesan error untuk mendapatkan panduan.

Backoff eksponensial

Dalam kasus yang jarang terjadi, mungkin terjadi masalah dalam melayani permintaan Anda.Anda mungkin menerima kode respons HTTP 4XX atau 5XX, atau koneksi TCP mungkin gagal antara klien Anda dan server Google. Sering kali, tidak ada salahnya mencoba kembali permintaan tersebut. Permintaan tindak lanjut mungkin berhasil jika yang asli gagal. Namun, penting untuk tidak melakukan loop, berulang kali membuat permintaan ke server Google. Perilaku loop ini dapat membebani jaringan antara klien Anda dan Google serta menyebabkan masalah bagi banyak pihak.

Pendekatan terbaik adalah mencoba ulang dengan meningkatkan waktu tunda antar percobaan. Biasanya, penundaan ditingkatkan dengan faktor perkalian pada setiap percobaan, pendekatan ini dikenal sebagai Backoff eksponensial.

Anda juga harus berhati-hati agar tidak ada percobaan ulang kode yang lebih tinggi dalam rantai panggilan aplikasi yang menyebabkan permintaan berulang dalam urutan cepat.

Penggunaan Google API yang sopan

Klien API yang didesain dengan buruk dapat menempatkan beban lebih dari yang diperlukan di internet dan server Google. Bagian ini berisi beberapa praktik terbaik untuk klien API. Mengikuti praktik terbaik ini dapat membantu Anda menghindari aplikasi diblokir karena penyalahgunaan API yang tidak disengaja.

Permintaan yang disinkronkan

Sejumlah besar permintaan yang disinkronkan ke API Google dapat terlihat seperti serangan Distributed Denial of Service (DDoS) pada infrastruktur Google dan akan ditangani sebagaimana mestinya. Untuk menghindari hal ini, Anda harus memastikan bahwa permintaan API tidak disinkronkan antar-klien.

Misalnya, pertimbangkan aplikasi yang menampilkan waktu dalam zona waktu saat ini. Aplikasi ini mungkin akan menyetel alarm dalam sistem operasi klien yang membangunkannya di awal menit, sehingga waktu yang ditampilkan dapat diperbarui. Aplikasi tidak boleh melakukan panggilan API apa pun sebagai bagian dari pemrosesan yang terkait dengan alarm tersebut.

Melakukan panggilan API sebagai respons terhadap alarm tetap tidak baik karena mengakibatkan panggilan API disinkronkan ke awal menit, bahkan di antara perangkat yang berbeda, bukan didistribusikan secara merata dari waktu ke waktu. Aplikasi yang didesain dengan buruk yang melakukan ini akan menghasilkan lonjakan traffic pada enam puluh kali dari level normal di awal setiap menit.

Sebagai gantinya, salah satu desain yang bagus adalah menyetel alarm kedua ke waktu yang dipilih secara acak. Saat alarm kedua ini dipicu, aplikasi akan melakukan panggilan ke API apa pun yang diperlukan dan menyimpan hasilnya. Untuk mengupdate tampilannya di awal menit, aplikasi menggunakan hasil yang disimpan sebelumnya, bukan memanggil API lagi. Dengan pendekatan ini, panggilan API tersebar dengan rata. Selain itu, panggilan API tidak menunda rendering saat tampilan diupdate.

Selain awal menit, waktu sinkronisasi umum lainnya yang harus berhati-hati agar tidak ditargetkan adalah di awal satu jam dan awal setiap hari pada tengah malam.