แนวทางปฏิบัติแนะนำ

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

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

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

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

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

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

การแคช

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

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

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

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

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

การเข้าถึง SSL

ต้องใช้ HTTPS สําหรับคําขอบริการเว็บไลบรารีทั้งหมดที่ใช้ URL ต่อไปนี้

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

คําขอที่ส่งผ่าน HTTP จะถูกปฏิเสธ

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

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

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

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

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

Exponential Backoff

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

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

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

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

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

คําขอที่ซิงค์

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

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

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

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

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