การให้สิทธิ์
คำขอทั้งหมดที่ส่งไปยัง Google Photos Library API ต้องได้รับอนุญาตจากผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว
รายละเอียดของขั้นตอนการให้สิทธิ์สำหรับ OAuth 2.0 จะแตกต่างกันเล็กน้อยโดยขึ้นอยู่กับประเภทของแอปพลิเคชันที่คุณเขียน ขั้นตอนทั่วไปต่อไปนี้มีผลกับแอปพลิเคชันทุกประเภท
- เตรียมพร้อมสำหรับขั้นตอนการให้สิทธิ์โดยดำเนินการดังต่อไปนี้
- ลงทะเบียนแอปพลิเคชันโดยใช้คอนโซล Google API
- เปิดใช้ Library API และเรียกข้อมูลรายละเอียด OAuth เช่น รหัสไคลเอ็นต์และรหัสลับไคลเอ็นต์ ดูข้อมูลเพิ่มเติมได้ที่เริ่มต้นใช้งาน
- ในการเข้าถึงข้อมูลผู้ใช้ แอปพลิเคชันจะส่งคำขอไปยัง Google สำหรับขอบเขตการเข้าถึงที่เฉพาะเจาะจง
- Google จะแสดงหน้าจอขอความยินยอมต่อผู้ใช้เพื่อขอให้ผู้ใช้ให้สิทธิ์แอปพลิเคชันในการขอข้อมูลบางอย่างของผู้ใช้
- หากผู้ใช้อนุมัติ Google จะให้โทเค็นเพื่อการเข้าถึงแก่แอปพลิเคชันซึ่งจะหมดอายุในช่วงระยะเวลาสั้นๆ
- แอปพลิเคชันจะส่งคำขอข้อมูลผู้ใช้โดยแนบโทเค็นเพื่อการเข้าถึงไปกับคำขอ
- หาก Google พิจารณาเห็นว่าคำขอและโทเค็นถูกต้อง ระบบจะแสดงข้อมูลที่ขอ
หากต้องการดูว่าขอบเขตใดเหมาะกับแอปพลิเคชันของคุณ โปรดดูที่ขอบเขตการให้สิทธิ์
กระบวนการสำหรับแอปพลิเคชันบางประเภทจะมีขั้นตอนเพิ่มเติม เช่น การใช้โทเค็นการรีเฟรชเพื่อขอโทเค็นเพื่อการเข้าถึงใหม่ ดูข้อมูลโดยละเอียดเกี่ยวกับขั้นตอนของแอปพลิเคชันประเภทต่างๆ ได้ที่การใช้ OAuth 2.0 เพื่อเข้าถึง Google API
การแคช
อัปเดตข้อมูลอยู่เสมอ
หากคุณต้องการจัดเก็บสื่อไว้ชั่วคราว (เช่น ภาพขนาดย่อ รูปภาพ หรือวิดีโอ) เพื่อเหตุผลด้านประสิทธิภาพ อย่าใช้แคชเกินกว่า 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 จะไม่ทำให้การแสดงผลล่าช้าลงเมื่ออัปเดตจอแสดงผล
นอกเหนือจากจุดเริ่มต้นนาทีแล้ว เวลาซิงค์ทั่วไปอื่นๆ ที่คุณควรระวังอย่ากำหนดเป้าหมายคือช่วงเริ่มต้นชั่วโมงและตอนเริ่มต้นของแต่ละวันตอนเที่ยงคืน