ปรับปรุงประสิทธิภาพ

เอกสารนี้ครอบคลุมเทคนิคบางประการที่คุณสามารถใช้เพื่อปรับปรุงประสิทธิภาพของแอปพลิเคชันของคุณ ในบางกรณี ตัวอย่างจาก API อื่นๆ หรือ API ทั่วไปจะใช้เพื่อแสดงตัวอย่างแนวคิดที่นำเสนอ อย่างไรก็ตาม Android Over The Air API ก็ใช้แนวคิดเดียวกันนี้ได้

การบีบอัดโดยใช้ gzip

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

หากต้องการรับการตอบกลับที่เข้ารหัสด้วย gzip คุณต้องทำ 2 อย่าง ได้แก่ ตั้งค่าส่วนหัว Accept-Encoding และแก้ไข User Agent ให้มีสตริง gzip ต่อไปนี้คือตัวอย่างของส่วนหัว HTTP ที่มีรูปแบบถูกต้องสำหรับการเปิดใช้การบีบอัด gzip

Accept-Encoding: gzip
User-Agent: my program (gzip)

การทำงานกับทรัพยากรบางส่วน

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

คำขอบางส่วนมี 2 ประเภท ได้แก่

• การตอบกลับบางส่วน: คำขอที่คุณระบุช่องที่จะรวมไว้ในการตอบกลับ (ใช้พารามิเตอร์คำขอ fields)
• แพตช์: คำขออัปเดตที่คุณส่งเฉพาะช่องที่ต้องการเปลี่ยน (ใช้คำกริยา HTTP PATCH)

โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับการสร้างคำขอบางส่วนในหัวข้อต่อไปนี้

คำตอบบางส่วน

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

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

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

ตัวอย่าง

แพตช์ (อัปเดตบางส่วน)

นอกจากนี้คุณยังหลีกเลี่ยงการส่งข้อมูลที่ไม่จำเป็นเมื่อแก้ไขทรัพยากรได้ หากต้องการส่งข้อมูลที่อัปเดตสำหรับฟิลด์ที่คุณกำลังเปลี่ยนแปลงเท่านั้น ให้ใช้กริยา HTTP PATCH อรรถศาสตร์ของแพตช์ที่อธิบายในเอกสารนี้แตกต่าง (และง่ายกว่า) จากการใช้งาน GData เดิมของการอัปเดตบางส่วน

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

ตัวอย่าง

การจัดการกับคำตอบสำหรับแพตช์

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

คำขอแพตช์จะแสดงการแสดงทรัพยากรทั้งหมด เว้นแต่คุณจะใช้พารามิเตอร์ fields เพื่อลดปริมาณข้อมูลที่จะแสดง

หากคำขอแพตช์ทำให้เกิดสถานะทรัพยากรใหม่ที่ไม่ถูกต้องตามไวยากรณ์หรือเชิงความหมาย เซิร์ฟเวอร์จะแสดงรหัสสถานะ HTTP 400 Bad Request หรือ 422 Unprocessable Entity และสถานะทรัพยากรจะไม่มีการเปลี่ยนแปลง เช่น หากคุณพยายามลบค่าของช่องที่ต้องกรอก เซิร์ฟเวอร์จะแสดงข้อผิดพลาด

สัญลักษณ์สำรองเมื่อไม่สนับสนุนคำกริยา HTTP ของ PATCH

หากไฟร์วอลล์ของคุณไม่อนุญาตคำขอ HTTP PATCH ให้ส่งคำขอ HTTP POST แล้วตั้งค่าส่วนหัวการลบล้างเป็น PATCH ดังที่แสดงด้านล่าง

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

ความแตกต่างระหว่างแพตช์และการอัปเดต

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

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