Praktik terbaik

Catatan: Halaman ini berfokus pada praktik terbaik teknis untuk penggunaan Photos API yang optimal. Untuk mengetahui informasi tentang kebijakan dan pedoman API, lihat Kebijakan Data Pengguna dan Developer API Google Foto.

Otorisasi

Semua permintaan ke Google Photos API harus diizinkan oleh pengguna terautentikasi.

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 Google API.
   • Aktifkan Photos API dan ambil detail OAuth seperti client ID dan secret client. Untuk 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 memberikan token akses ke aplikasi yang akan berakhir masa berlakunya setelah beberapa saat.
5. Aplikasi membuat permintaan untuk data pengguna, dengan melampirkan token akses ke permintaan.
6. Jika Google menentukan bahwa permintaan dan token tersebut valid, Google akan menampilkan data yang diminta.

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

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

Catatan: Mengingat implikasi keamanan untuk mendapatkan penerapan yang benar, sebaiknya Anda menggunakan library OAuth 2.0 saat berinteraksi dengan endpoint OAuth 2.0 Google. Praktik terbaiknya adalah menggunakan kode yang telah di-debug dengan baik yang disediakan oleh orang lain, dan hal ini membantu Anda melindungi diri sendiri dan pengguna. Untuk informasi selengkapnya, lihat Library klien OAuth 2.0.

Menyimpan ke cache

Catatan: Khusus untuk Library API

Pastikan data selalu diperbarui.

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

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

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

Jika Anda memiliki banyak item media yang akan diperbarui, sebaiknya simpan parameter penelusuran yang menampilkan item media dan kirim ulang kueri untuk memuat ulang data.

Akses SSL

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

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

Permintaan yang dibuat melalui HTTP akan ditolak.

Penanganan error

Untuk informasi tentang cara menangani error yang ditampilkan dari API, lihat Penanganan error Cloud API.

Mencoba lagi permintaan yang gagal

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

Untuk error 429, klien dapat mencoba lagi dengan penundaan 30s minimum. 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, bisa terjadi sesuatu yang salah saat melayani permintaan Anda.Anda dapat menerima kode respons HTTP 4XX atau 5XX, atau koneksi TCP dapat mengalami kegagalan antara klien Anda dan server Google. Sering kali, sebaiknya coba lagi permintaan. Permintaan tindak lanjut mungkin berhasil saat permintaan asli gagal. Namun, penting untuk tidak membuat loop, berulang kali membuat permintaan ke server Google. Perilaku loop ini dapat menyebabkan kelebihan beban pada jaringan antara klien Anda dan Google serta menyebabkan masalah bagi banyak pihak.

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

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

Penggunaan moderat Google API

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

Permintaan yang disinkronkan

Sejumlah besar permintaan yang disinkronkan ke Google API bisa tampak seperti serangan DDoS (Distributed Denial of Service) pada infrastruktur Google, dan akan diperlakukan sebagai DDoS. Untuk menghindarinya, Anda harus memastikan bahwa permintaan API tidak disinkronkan antara klien.

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

Membuat panggilan API sebagai respons terhadap alarm tetap dianggap buruk karena menyebabkan panggilan API disinkronkan ke awal menit, bahkan antara perangkat yang berbeda, bukannya didistribusikan secara merata dari waktu ke waktu. Aplikasi yang dirancang dengan buruk yang melakukan ini akan menghasilkan lonjakan traffic sebesar enam puluh kali dari tingkat normal di awal setiap menit.

Sebagai gantinya, satu rancangan yang mungkin baik adalah menyetel alarm kedua ke waktu yang dipilih secara acak. Saat alarm kedua terpicu, aplikasi akan melakukan panggilan ke API apa pun yang diperlukannya dan menyimpan hasilnya. Untuk memperbarui 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 sedang diperbarui.

Selain awal menit, waktu sinkronisasi umum lainnya yang harus Anda perhatikan agar tidak ditargetkan adalah di awal jam dan awal setiap hari pada tengah malam.