การออกแบบ REST API: การโทรหลายครั้งกับการโทรครั้งเดียวไปยัง API

เรากำลังพัฒนา Rest API สำหรับเว็บไซต์อีคอมเมิร์ซซึ่งแอพมือถือจะถูกใช้งาน

ในหน้าแรกของแอพเราจำเป็นต้องโทรหาแหล่งข้อมูลมากมายเช่นสไลเดอร์แบรนด์ยอดนิยมสินค้าขายดี

สองตัวเลือกในการโทรด้วย API:

โทรเดียว:

www.example.com/api/GetAllInHome

โทรหลายสาย:

www.example.com/api/GetSliders

www.example.com/api/GetTopBrands

www.example.com/api/GetBestSellingProducts

www.example.com/api/GetTrendingProducts

ซึ่งเป็นวิธีที่ดีที่สุดสำหรับการออกแบบ api พักผ่อน - โทรเดียวหรือหลายอธิบายข้อดีและข้อเสีย?

ซึ่งจะใช้เวลามากขึ้นในการตอบสนองต่อการร้องขอ?

— shaijut
แหล่งที่มา

คำตอบ:

ในทฤษฎีการโทรหลายสายพร้อมกันนั้นยืดหยุ่นกว่าและเร็วกว่า

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

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

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

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

— Ewan
แหล่งที่มา

ขอบคุณจริง ๆ แล้ว API นี้ถูกใช้ใน Android และ i phone apps ฉันต้องการทราบว่าเมื่อใดที่หน้าแรกของแอปโหลดขึ้นมาฉันควรจะได้รับทรัพยากรทั้งหมดเช่น: แถบเลื่อนแบรนด์ผลิตภัณฑ์ในการโทร api เดี่ยวหรือโทรหา api แต่ละครั้ง ผู้ใช้เลื่อนลงมา?

— shaijut

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

— Ewan

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

— shaijut

ไม่เว้นเสียแต่ว่าคุณจะมีเหตุผลที่ดีว่าทำไมส่วนเหล่านั้นไม่ได้ถูกโหลดด้วยหน้า / ข้อมูลหลัก

— Ewan

ฉันมีคำถามสุดท้ายว่าแอพเช่น amazon, flipkart ทำงานอย่างไร พวกเขาไม่โหลดทรัพยากรโฮมเพจทั้งหมดในการโทรครั้งเดียวเมื่อผู้ใช้เปิดแอปหรือไม่ ฉันต้องการที่จะรู้ว่าสิ่งที่จะเป็นวิธีที่ดีที่สุดในเรื่องนี้

— shaijut

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

อย่างไรก็ตามในกรณีของคุณฉันไม่แน่ใจว่าเป็นเรื่องเต็ม

REST API เป็นคำที่คลุมเครือเล็กน้อยเนื่องจากการตีความที่หลากหลายของกระดาษที่ทำให้ความคิดเป็นที่นิยม แม้กระทั่งการตีความอย่างเสรีที่สุดในสิ่งที่ถือเป็น REST API อย่างไรก็ตามสิ่งที่คุณไม่ได้เหมาะสม

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

ในกรณีเฉพาะของคุณวิธีการทั้งหมดของคุณมีคำว่า 'รับ' ในชื่อของพวกเขา คุณควรเปลี่ยนคำกริยาที่ใช้ในคำขอ HTTP เพื่อระบุว่าคุณต้องการ 'รับ' ทรัพยากรที่มีอยู่ในตำแหน่งนั้น

แบบแผน URI ของคุณควรแสดงลำดับชั้นทางลอจิคัลของทรัพยากรที่คุณต้องการให้ผู้ใช้ API ใช้งานได้ดังนั้นในกรณีของคุณฉันควรพิจารณาใช้สิ่งที่ต้องการ/api/products?category=slidersกรองชุดผลิตภัณฑ์ของคุณ ซึ่งหมายความว่าเมื่อลูกค้าต้องการได้รับผลิตภัณฑ์ทั้งหมดของพวกเขาพวกเขาก็สามารถละเว้นสตริงแบบสอบถาม

— richzilla
แหล่งที่มา

ขอบคุณดังนั้นคุณหมายถึง single urlสำหรับ API แต่การร้องขอไปยังแหล่งข้อมูลต่าง ๆ ควรใช้ Query String หรือไม่ ตรวจสอบสิ่งนี้ด้วย

— shaijut

ใช่การโทรของคุณแบบอะซิงโครนัสจะลดเวลาที่แน่นอนในการดึงข้อมูล แต่โดยรวมเวลาที่ใช้จะยังคงมีมากขึ้น การโทรจำนวนมากจะต้องทำซ้ำโอเวอร์เฮดของการเชื่อมต่อ TCP และการสื่อสารแบบไปกลับ แม้กระทั่งการใช้คุณสมบัติเช่นkeep-alivearent จะลบสิ่งนี้อย่างสิ้นเชิง

— richzilla

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

— richzilla

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

— shaijut

ขึ้นอยู่กับสิ่งที่ผู้ใช้คาดว่าจะเห็นในแต่ละจุดในแอปพลิเคชันของคุณ ยกตัวอย่างเว็บไซต์นี้เมื่อคุณคลิกที่questionsคุณเห็น URI คือ/questionsเมื่อคุณคลิกที่หนึ่งในแท็กที่คุณชื่นชอบ URI คือ/questions/tagged/<tagname>

— richzilla