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

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

คำขอทั้งหมดที่ส่งไปยัง 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

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

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

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

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

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

การลองส่งคำขอที่ไม่สำเร็จอีกครั้ง

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

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

Exponential Backoff

ในบางกรณีที่พบไม่บ่อยนัก อาจมีบางอย่างผิดพลาดในการส่งคำขอ คุณอาจได้รับโค้ดตอบกลับ HTTP 4XX หรือ 5XX หรือการเชื่อมต่อ TCP อาจไม่สำเร็จระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ของ Google บ่อยครั้งที่คุณควรลองส่งคำขออีกครั้ง คำขอติดตามผลอาจสำเร็จเมื่อคำขอแรกไม่สำเร็จ อย่างไรก็ตาม สิ่งสำคัญคืออย่าส่งคำขอไปยังเซิร์ฟเวอร์ของ Google ซ้ำๆ ลักษณะการทำงานแบบวนซ้ำนี้อาจทำให้เครือข่ายระหว่างไคลเอ็นต์กับ Google ทำงานหนักเกินไปและก่อให้เกิดปัญหากับหลายฝ่าย

วิธีที่ดีกว่านั้นคือลองอีกครั้งโดยเพิ่มความล่าช้าระหว่างการลอง โดยปกติแล้ว ระบบจะเพิ่มการหน่วงเวลาตามปัจจัยการคูณกับการพยายามแต่ละครั้ง ซึ่งเป็นแนวทางที่เรียกว่าการถดถอยแบบทวีคูณ

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

การใช้ Google APIs อย่างสุภาพ

ไคลเอ็นต์ API ที่ออกแบบมาไม่ดีอาจทําให้อินเทอร์เน็ตและเซิร์ฟเวอร์ของ Google มีภาระงานมากกว่าที่จําเป็น ส่วนนี้มีแนวทางปฏิบัติแนะนำสำหรับไคลเอ็นต์ของ API การปฏิบัติตามแนวทางปฏิบัติแนะนำเหล่านี้จะช่วยให้แอปพลิเคชันของคุณไม่ถูกบล็อกเนื่องจากการละเมิด API โดยไม่ได้ตั้งใจ

คำขอที่ซิงค์

คำขอที่ซิงค์จำนวนมากไปยัง API ของ Google อาจดูเหมือนการโจมตีแบบปฏิเสธการให้บริการแบบกระจาย (DDoS) โครงสร้างพื้นฐานของ Google และระบบอาจดำเนินการกับคำขอดังกล่าวตามความเหมาะสม คุณควรตรวจสอบว่าคำขอ API ไม่ได้ซิงค์กันระหว่างไคลเอ็นต์ต่างๆ เพื่อหลีกเลี่ยงปัญหานี้

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

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

แต่การออกแบบที่ดีอย่างหนึ่งคือการตั้งปลุกครั้งที่ 2 เป็นเวลาที่เลือกแบบสุ่ม เมื่อการแจ้งเตือนครั้งที่ 2 นี้ทำงาน แอปพลิเคชันจะเรียกใช้ API ที่ต้องการและจัดเก็บผลลัพธ์ หากต้องการอัปเดตการแสดงผลเมื่อเริ่มนาที แอปพลิเคชันจะใช้ผลลัพธ์ที่เก็บไว้ก่อนหน้านี้แทนการเรียกใช้ API อีกครั้ง เมื่อใช้วิธีนี้ การเรียก API จะกระจายอย่างสม่ำเสมอเมื่อเวลาผ่านไป นอกจากนี้ การเรียก API จะไม่ทำให้การแสดงผลล่าช้าเมื่อมีการอัปเดตจอแสดงผล

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