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

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

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

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

การแคช

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

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

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

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

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

การเข้าถึง SSL

ต้องใช้ HTTPS สำหรับคำขอบริการเว็บของ Library 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 ทำงานหนักเกินไป และก่อให้เกิดปัญหาต่อหลายๆ ฝ่าย

วิธีการที่ดีกว่าคือลองอีกครั้งโดยให้เกิดความล่าช้ามากขึ้นระหว่างการดำเนินการแต่ละครั้ง โดยปกติแล้ว ความล่าช้าจะเพิ่มขึ้นตามปัจจัยต่างๆ ในการลองแต่ละครั้ง หรือวิธีการที่เรียกว่า Exponential Backoff

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

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

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

คำขอที่ซิงค์ไว้

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

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

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

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

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