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

เอกสารนี้ครอบคลุมเทคนิคบางอย่างที่คุณสามารถใช้เพื่อปรับปรุงประสิทธิภาพของแอปพลิเคชัน ในบางกรณี เราจะใช้ตัวอย่างจาก 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)
• Patch: คำขออัปเดตที่คุณส่งเฉพาะฟิลด์ที่ต้องการเปลี่ยนแปลง (ใช้กริยา HTTP PATCH)

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

คำตอบเพียงบางส่วน

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

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

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

Patch (การอัปเดตบางส่วน)

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

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

ตัวอย่าง

การจัดการการตอบกลับแพตช์

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

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

หากคำขอ PATCH ทำให้เกิดสถานะทรัพยากรใหม่ที่ใช้ไม่ได้ตามไวยากรณ์หรือความหมาย เซิร์ฟเวอร์จะแสดงรหัสสถานะ 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 คำขอจะล้มเหลวหากคุณไม่ได้ระบุพารามิเตอร์ที่จำเป็น และจะล้างข้อมูลที่ตั้งไว้ก่อนหน้านี้หากคุณไม่ได้ระบุพารามิเตอร์ที่ไม่บังคับ

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