แนวทางปฏิบัติที่ดี

การให้สิทธิ์

คำขอทั้งหมดที่ส่งไปยัง Google Photos API จะต้องได้รับสิทธิ์จากผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว

รายละเอียดของกระบวนการให้สิทธิ์สำหรับ OAuth 2.0 จะแตกต่างกันไปเล็กน้อยโดยขึ้นอยู่กับประเภทของแอปพลิเคชันที่คุณเขียน กระบวนการทั่วไปต่อไปนี้ มีผลกับแอปพลิเคชันทุกประเภท:

1. เตรียมความพร้อมสำหรับกระบวนการให้สิทธิ์โดยทำตามขั้นตอนต่อไปนี้
   • ลงทะเบียนแอปพลิเคชันโดยใช้คอนโซล Google API
   • เปิดใช้งาน Photos API และเรียกรายละเอียด OAuth เช่น และรหัสลับไคลเอ็นต์ สำหรับข้อมูลเพิ่มเติม โปรดดู เริ่มต้นใช้งาน
2. แอปพลิเคชันจะส่งคำขอขอบเขตการเข้าถึงที่เฉพาะเจาะจงไปยัง Google เพื่อเข้าถึงข้อมูลผู้ใช้
3. Google จะแสดงหน้าจอขอความยินยอมต่อผู้ใช้เพื่อขอให้ผู้ใช้ให้สิทธิ์ เพื่อขอข้อมูลบางส่วนได้
4. หากผู้ใช้อนุมัติ Google จะมอบโทเค็นการเข้าถึงแก่แอปพลิเคชันซึ่งจะหมดอายุหลังจากผ่านไประยะหนึ่ง
5. แอปพลิเคชันส่งคำขอข้อมูลผู้ใช้โดยแนบโทเค็นเพื่อการเข้าถึง เข้ากับคำขอ
6. หาก Google ตัดสินว่าคำขอและโทเค็นถูกต้อง ระบบจะแสดงข้อมูลที่ขอ

หากต้องการระบุขอบเขตที่เหมาะกับแอปพลิเคชัน โปรดดูที่การให้สิทธิ์ ขอบเขต

กระบวนการสำหรับแอปพลิเคชันบางประเภทจะมีขั้นตอนเพิ่มเติม เช่น การใช้ รีเฟรชโทเค็นเพื่อรับโทเค็นเพื่อการเข้าถึงใหม่ หากต้องการดูข้อมูลโดยละเอียดเกี่ยวกับ สำหรับแอปพลิเคชันประเภทต่างๆ โปรดดูการใช้ OAuth 2.0 เพื่อเข้าถึง Google API

การแคช

อัปเดตข้อมูลอยู่เสมอ

หากต้องการจัดเก็บสื่อ (เช่น ภาพขนาดย่อ รูปภาพ หรือวิดีโอ) ไว้ชั่วคราว เพื่อเหตุผลด้านประสิทธิภาพ โปรดอย่าแคชไว้นานเกิน 60 นาทีต่อการใช้งานของเรา หลักเกณฑ์

นอกจากนี้ คุณไม่ควรจัดเก็บ baseUrls ซึ่งจะหมดอายุหลังจากผ่านไปประมาณ 60 นาที

รหัสรายการสื่อและรหัสอัลบั้มที่ระบุเนื้อหาโดยไม่ซ้ำกันในไลบรารีของผู้ใช้ จะได้รับการยกเว้นจากข้อจำกัดการแคช คุณสามารถจัดเก็บรหัสเหล่านี้ไว้ได้แบบไม่มีกำหนดสิ้นสุด (ขึ้นอยู่กับนโยบายความเป็นส่วนตัวของแอปพลิเคชัน) ใช้รหัสรายการสื่อและรหัสอัลบั้ม เพื่อเรียก URL และข้อมูลที่เข้าถึงได้อีกครั้งโดยใช้ปลายทางที่เหมาะสม ดูข้อมูลเพิ่มเติมได้ที่รับรายการสื่อหรือการระบุอัลบั้ม

หากคุณมีรายการสื่อที่ต้องรีเฟรชหลายรายการ การจัดเก็บ พารามิเตอร์การค้นหาที่แสดงรายการสื่อและส่งคำค้นหาอีกครั้งเพื่อโหลดซ้ำ

การเข้าถึง SSL

จำเป็นต้องใช้ HTTPS สำหรับคำขอบริการผ่านเว็บ Photos API ทั้งหมดที่ใช้ URL ต่อไปนี้:

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

ระบบจะปฏิเสธคำขอที่ส่งผ่าน HTTP

การจัดการข้อผิดพลาด

ดูข้อมูลเกี่ยวกับวิธีจัดการข้อผิดพลาดที่แสดงผลจาก API ได้ที่การจัดการข้อผิดพลาดของ Cloud API

การลองส่งคำขอที่ล้มเหลวอีกครั้ง

ลูกค้าควรลองแก้ไขข้อผิดพลาด 5xx ที่มี Exponential Backoff อีกครั้งตามที่อธิบายไว้ใน Exponential Backoff ความล่าช้าขั้นต่ำควรเป็น 1 s เว้นแต่จะระบุไว้เป็นอย่างอื่น

สำหรับข้อผิดพลาด 429 ไคลเอ็นต์อาจลองอีกครั้งโดยมีความล่าช้าขั้นต่ำ 30s สำหรับข้อผิดพลาดอื่นๆ ทั้งหมด คุณอาจลองอีกครั้งไม่ได้ ตรวจสอบว่าคำขอของคุณเป็นนิจพลและ ข้อความแสดงข้อผิดพลาดเพื่อเป็นแนวทาง

Exponential Backoff

ในบางกรณีที่พบไม่บ่อยนัก อาจมีบางอย่างผิดพลาดในการส่งคำขอ คุณอาจได้รับโค้ดตอบกลับ HTTP 4XX หรือ 5XX หรือการเชื่อมต่อ 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 จะไม่ทำให้การแสดงผลล่าช้าเมื่อมีการอัปเดตจอแสดงผล

นอกจากเวลาเริ่มต้นของนาทีแล้ว เวลาซิงค์อื่นๆ ที่พบบ่อยซึ่งคุณควรระมัดระวังไม่ให้กําหนดเป้าหมาย ได้แก่ เวลาเริ่มต้นของชั่วโมงและเวลาเริ่มต้นของวันตอนเที่ยงคืน