การให้สิทธิ์
คำขอทั้งหมดที่ส่งไปยัง Google Photos Library API ต้องได้รับอนุญาตจากผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว
รายละเอียดของกระบวนการให้สิทธิ์สำหรับ OAuth 2.0 จะแตกต่างกันเล็กน้อย เกี่ยวกับประเภทของแอปพลิเคชันที่คุณกำลังเขียน กระบวนการทั่วไปต่อไปนี้ มีผลกับแอปพลิเคชันทุกประเภท:
- เตรียมความพร้อมสำหรับกระบวนการให้สิทธิ์โดยทำตามขั้นตอนต่อไปนี้
- ลงทะเบียนแอปพลิเคชันโดยใช้ Google API Console
- เปิดใช้งาน Library API และเรียกข้อมูลรายละเอียด OAuth เช่น และรหัสลับไคลเอ็นต์ สำหรับข้อมูลเพิ่มเติม โปรดดู เริ่มต้นใช้งาน
- ในการเข้าถึงข้อมูลผู้ใช้ แอปพลิเคชันจะส่งคำขอไปยัง Google ขอบเขตการเข้าถึงโดยเฉพาะ
- Google จะแสดงหน้าจอขอความยินยอมต่อผู้ใช้เพื่อขอให้ผู้ใช้ให้สิทธิ์ เพื่อขอข้อมูลบางส่วนได้
- หากผู้ใช้อนุมัติ Google จะให้โทเค็นเพื่อการเข้าถึงแก่แอปพลิเคชัน ซึ่งจะหมดอายุหลังจากผ่านไปช่วงสั้นๆ
- แอปพลิเคชันส่งคำขอข้อมูลผู้ใช้โดยแนบโทเค็นเพื่อการเข้าถึง ตามคำขอได้
- ถ้า Google พิจารณาว่าคำขอและโทเค็นถูกต้อง ระบบจะแสดง ข้อมูลที่ขอ
หากต้องการระบุขอบเขตที่เหมาะกับแอปพลิเคชัน โปรดดูที่การให้สิทธิ์ ขอบเขตการใช้งาน
กระบวนการสำหรับแอปพลิเคชันบางประเภทจะมีขั้นตอนเพิ่มเติม เช่น การใช้ รีเฟรชโทเค็นเพื่อรับโทเค็นเพื่อการเข้าถึงใหม่ หากต้องการดูข้อมูลโดยละเอียดเกี่ยวกับ สำหรับแอปพลิเคชันประเภทต่างๆ โปรดดูการใช้ OAuth 2.0 เพื่อเข้าถึง Google API
การแคช
อัปเดตข้อมูลอยู่เสมอ
หากต้องการจัดเก็บสื่อ (เช่น ภาพขนาดย่อ รูปภาพ หรือวิดีโอ) ไว้ชั่วคราว เพื่อเหตุผลด้านประสิทธิภาพ โปรดอย่าแคชไว้นานเกิน 60 นาทีต่อการใช้งานของเรา หลักเกณฑ์
นอกจากนี้ คุณไม่ควรจัดเก็บ baseUrls ซึ่งจะหมดอายุหลังจากผ่านไปประมาณ 60 ปี
นาที
รหัสรายการสื่อและรหัสอัลบั้มที่ระบุเนื้อหาโดยไม่ซ้ำกันในไลบรารีของผู้ใช้ จะได้รับการยกเว้นจากข้อจำกัดการแคช คุณจะจัดเก็บรหัสเหล่านี้ไว้แบบไม่มีกำหนดสิ้นสุด (ขึ้นอยู่กับนโยบายส่วนบุคคลของแอปพลิเคชันของคุณ) ใช้รหัสรายการสื่อและรหัสอัลบั้ม เพื่อเรียก URL และข้อมูลที่เข้าถึงได้อีกครั้งโดยใช้ปลายทางที่เหมาะสม สำหรับ ข้อมูลเพิ่มเติม โปรดดูหัวข้อรับสื่อ item หรือรายชื่อ อัลบั้ม
หากคุณมีรายการสื่อที่ต้องรีเฟรชหลายรายการ การจัดเก็บ พารามิเตอร์การค้นหาที่แสดงรายการสื่อและส่งคำค้นหาอีกครั้งเพื่อโหลดซ้ำ
การเข้าถึง SSL
จำเป็นต้องใช้ HTTPS สำหรับคำขอบริการเว็บ Library API ทั้งหมดที่ใช้ URL ต่อไปนี้:
https://photoslibrary.googleapis.com/v1/service/output?parameters
คำขอที่ส่งผ่าน HTTP จะถูกปฏิเสธ
การจัดการข้อผิดพลาด
โปรดดูข้อมูลเกี่ยวกับวิธีจัดการข้อผิดพลาดที่แสดงผลจาก API ที่หัวข้อระบบคลาวด์ API การจัดการ ข้อผิดพลาด
การลองส่งคำขอที่ล้มเหลวอีกครั้ง
ลูกค้าควรลองแก้ไขข้อผิดพลาด 5xx ที่มี Exponential Backoff อีกครั้งตามที่อธิบายไว้ใน
Exponential Backoff ความล่าช้าขั้นต่ำควรเป็น 1 s
เว้นแต่จะระบุไว้เป็นอย่างอื่น
สำหรับข้อผิดพลาด 429 รายการ ไคลเอ็นต์อาจลองอีกครั้งโดยล่าช้าอย่างน้อย 30s สำหรับช่องทางอื่นๆ ทั้งหมด
คุณอาจไม่สามารถลองอีกครั้งได้ ตรวจสอบว่าคำขอของคุณเป็นนิจพลและ
ข้อความแสดงข้อผิดพลาดเพื่อเป็นแนวทาง
Exponential Backoff
ในบางกรณีที่เกิดขึ้นไม่บ่อยนัก อาจมีข้อผิดพลาดขณะดำเนินการตามคำขอ คุณอาจได้รับ
4XX หรือ 5XX โค้ดตอบกลับ HTTP หรือการเชื่อมต่อ TCP อาจล้มเหลวที่ใดที่หนึ่ง
ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ของ Google บ่อยครั้ง คุ้มค่าที่จะลอง
อีกครั้ง คำขอติดตามผลอาจดำเนินการสำเร็จเมื่อการดำเนินการเดิมล้มเหลว อย่างไรก็ตาม
สิ่งสำคัญคือต้องไม่ส่งคำขอซ้ำๆ ไปยังเซิร์ฟเวอร์ของ Google ช่วงเวลานี้
การวนซ้ำอาจทำให้เครือข่ายระหว่างไคลเอ็นต์ของคุณกับ Google ทำงานหนักเกินไป
สร้างปัญหาให้กับหลายฝ่าย
วิธีที่ดีกว่าคือลองอีกครั้งโดยให้ความล่าช้าเพิ่มขึ้นระหว่างการดำเนินการแต่ละครั้ง โดยทั่วไป ความล่าช้าจะเพิ่มขึ้นตามตัวคูณของความพยายามแต่ละครั้ง วิธีการ เรียกว่าเอกซ์โพเนนเชียล Backoff
คุณควรระมัดระวังไม่ให้ลองเขียนโค้ดอีกครั้งในแอปพลิเคชัน เชนการเรียกที่นำไปสู่คำขอซ้ำๆ ติดต่อกันอย่างรวดเร็ว
การใช้ Google APIs อย่างสุภาพ
ไคลเอ็นต์ API ที่ออกแบบไว้ไม่ดีอาจมีภาระงานมากเกินความจำเป็นทั้งในส่วนของ อินเทอร์เน็ตและบนเซิร์ฟเวอร์ของ Google ส่วนนี้ประกอบด้วยแนวทางปฏิบัติแนะนำสำหรับ ไคลเอ็นต์ของ API การปฏิบัติตามแนวทางปฏิบัติแนะนำต่อไปนี้จะช่วยให้คุณหลีกเลี่ยง แอปพลิเคชันถูกบล็อกเนื่องจากการใช้ API ในทางที่ผิดโดยไม่ตั้งใจ
คำขอที่ซิงค์
คำขอที่ซิงค์จำนวนมากไปยัง API ของ Google อาจดูเหมือน การโจมตีแบบปฏิเสธการให้บริการแบบกระจาย (DDoS) บนโครงสร้างพื้นฐานของ Google และ อย่างเหมาะสม เพื่อหลีกเลี่ยงเหตุการณ์นี้ คุณควรตรวจสอบว่าคำขอ API ไม่ซิงค์ข้อมูลระหว่างไคลเอ็นต์
ตัวอย่างเช่น ลองพิจารณาแอปพลิเคชันที่แสดงเวลาตามเวลาปัจจุบัน แอปพลิเคชันนี้น่าจะตั้งปลุกในระบบปฏิบัติการของไคลเอ็นต์ ปลุกระบบตอนเริ่มต้นนาที เพื่อให้เวลาที่แสดง อัปเดตแล้ว แอปพลิเคชันไม่ควรเรียกใช้ API ใดๆ ในกระบวนการประมวลผล ที่เชื่อมโยงกับการปลุกนั้น
การเรียก API ตามการปลุกแบบคงที่นั้นไม่ดีเพราะจะส่งผลให้เกิด การเรียก API ที่ซิงค์ตั้งแต่ต้นนาที แม้ว่าจะระหว่าง แทนการกระจายให้เท่าๆ กันเมื่อเวลาผ่านไป ออกแบบไม่ดี แอปพลิเคชันที่กำลังดำเนินการทำให้มีจำนวนการเข้าชมเพิ่มขึ้นที่ระดับปกติถึง 60 เท่า ที่จุดเริ่มต้นของแต่ละนาที
ดีไซน์ที่ดีอย่างหนึ่งที่เป็นไปได้คือ ตั้งปลุกครั้งที่ 2 แบบสุ่มๆ เวลาที่เลือกไว้ เมื่อการปลุกครั้งที่ 2 เริ่มทํางาน แอปพลิเคชันจะเรียกไปยัง API ที่จำเป็นต้องใช้และจัดเก็บผลลัพธ์ หากต้องการอัปเดตการแสดงผลเมื่อเริ่มต้น แอปพลิเคชันจะใช้ผลลัพธ์ที่จัดเก็บไว้ก่อนหน้านี้แทนการเรียกใช้ API อีกครั้ง วิธีนี้ทำให้การเรียก API กระจายอย่างเท่าๆ กันเมื่อเวลาผ่านไป นอกจากนั้น การเรียก API จะไม่ทำให้การแสดงผลล่าช้าขณะอัปเดตการแสดงผล
นอกเหนือจากการเริ่มต้นนาทีแล้ว เวลาซิงค์ทั่วไปอื่นๆ ที่คุณ ควรระวังอย่ากำหนดเป้าหมายเมื่อเริ่มต้นชั่วโมงและตอนต้นของ ตอนเที่ยงคืนทุกวัน