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

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

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