เมื่อสร้าง api ฉันควรติดกับฟังก์ชั่นขนาดเล็กและการโทรจำนวนมากหรือไม่กี่สายและฟังก์ชั่นขนาดใหญ่?


25

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

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

ดังนั้นคำถามของฉันเมื่อสร้าง API คือ:

เมื่อฉันต้องทำสิ่งต่างๆมากมายเช่นการvalidateสร้างuser, user profileและpolicyสวยมากในเวลาเดียวกัน ฉันควรทำการโทรแบบแยก 4 ครั้งและให้ลูกค้าสร้างการโทร 4 ครั้งที่ด้านข้าง หรือฉันควรจะมีหนึ่งสายที่ยกเว้นพารามิเตอร์จำนวนมากที่ตรวจสอบลูกค้าและสร้างทั้ง 3 สิ่งในเวลาเดียวกันทำให้สิ่งต่าง ๆ ง่ายขึ้นสำหรับลูกค้า?

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

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

คุณจะแนะนำให้ฉันแก้ไขปัญหานี้ได้อย่างไร

ตามที่ทราบมาฉันไม่มั่นใจในความสามารถของลูกค้าในการนำ API ที่ซับซ้อนมาใช้

คำตอบ:


32

วิธีทำทั้งสองอย่าง? มีAPI " ระดับต่ำ " (เพื่อพูด) ที่แสดงถึงการทำงานของระบบและมี "เลเยอร์" อีกอันที่เปิดเผยบริการที่ลูกค้าอาจต้องการทำ เลเยอร์นี้จะใช้ API ระดับต่ำที่จำเป็น แต่ก็ยังคงเปิดเผยหากลูกค้าต้องการ

UPDATE: เพื่อรวมคะแนนที่ยอดเยี่ยมและความคิดเห็นของผู้อื่น

  1. พิจารณาว่าลูกค้าจะต้องเรียกใช้หนึ่งในวิธีการ API ที่เล็กกว่าเช่นมันเป็นไปได้หรือไม่ที่จะเรียกใช้ createUserProfile โดยไม่ต้องเรียกใช้ createUser ด้วย? ถ้าไม่เช่นนั้นอย่าเปิดเผยวิธีการนั้น ขอบคุณNoobsArePeople2

  2. จุดที่เรียบง่าย แต่ยอดเยี่ยม จุดสำคัญที่มีการเปิดเผยบางสิ่งใน API - คุณไม่สามารถยกเลิกการเปิดเผยได้ เปิดเผยขั้นต่ำที่จำเป็นในการทำงานและการขยายแล้วมากกว่าการเปิดเผยทุกอย่างและ ... ดีแล้วการเปลี่ยนแปลงเปลือยกายและทำให้มันสามารถเป็นที่น่าอับอายและน่าอึดอัดใจ ขอบคุณMichaelT


10
+1 จะพูดอะไรแบบนี้ อีกคำถามที่จะถาม: คุณเคยทำสิ่งเหล่านี้แยกกับลูกค้าหรือไม่ เช่นลูกค้าจะต้องโทรไปcreateUserProfileโดยไม่ต้องด้วยcreateUserหรือไม่ ถ้าไม่เช่นนั้นอย่าเปิดเผยมัน
NoobsArePeople2

4
@ NoobsArePeople2 จุดที่ดีเยี่ยมในกรณีที่ไม่จำเป็นต้องแล้วอย่าเปิดเผยมัน
dreza

9
จุดสำคัญที่มีการเปิดเผยบางสิ่งใน API - คุณไม่สามารถยกเลิกการเปิดเผยได้ เปิดเผยขั้นต่ำที่จำเป็นในการใช้งานแล้วขยายแทนที่จะเปิดเผยทุกอย่างและ ... ดีจากนั้นการเปลี่ยนแปลงที่เปลือยเปล่าและการเปลี่ยนแปลงอาจทำให้เกิดความอับอายและน่าอึดอัดใจ

1
@ryanOptini ใช่นั่นคือบรรทัดที่ฉันจะลง แต่ถ้าคุณออกแบบการโทรเหล่านั้นในแบบ API การเปิดเผยเลเยอร์นั้นไม่น่าจะมีปัญหา
dreza

1
@ryanOptini สิ่งที่ dreza พูด
NoobsArePeople2

10

ฉันคิดว่าคุณกำลังมองมันในทางที่ผิด ไม่ต้องกังวลเรื่องใหญ่ สายเล็ก ๆ หรือ | โทรน้อย

คิดถึงวัตถุทางธุรกิจและการกระทำที่สามารถทำได้ด้วย | สำหรับ | กับวัตถุเหล่านั้น

คุณได้:

  • ผู้ใช้
  • นโยบาย
  • ราคา
  • ...

ดังนั้นคุณควรสร้างการเรียก API รอบ ๆ วัตถุเหล่านั้น

  • User.Create
  • User.UpdatePassword
  • Policy.Validate
  • ...

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

ปัญหาของการโทรที่มีขนาดใหญ่และ all-in-one มีความเสี่ยงของผลข้างเคียง หาก Policy.Create ยังวางไข่ผู้ใช้และก่อให้เกิดการกระทำอื่น ๆ แล้วนั่นจะทำลายความคาดหวังของโปรแกรมเมอร์ ในทำนองเดียวกันการเรียกใช้ขนาดเล็กจำนวนมากบังคับให้โปรแกรมเมอร์จำการเรียก A และ B และ C ตามด้วย C เพื่อดำเนินการทางธุรกิจ "เดี่ยว"

และวิธีที่คุณตั้งชื่อการโทรนั้นจะขึ้นอยู่กับ Rails และเว็บเซอร์วิสที่สนับสนุนของคุณ

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


4

ฉันคิดว่าความรู้สึกของคุณถูกต้อง - ทำให้ API ง่ายสำหรับผู้บริโภค ที่มีขอบเขตนี้เป็นปรัชญาที่อยู่เบื้องหลังผู้บริโภคขับเคลื่อนสัญญา

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


1
นอกจากนี้ API อย่างง่ายไม่จำเป็นต้องหมายถึงฟังก์ชั่นขนาดใหญ่ ฟังก์ชัน API สามารถเป็น "orchestrator" ซึ่งเรียกใช้ฟังก์ชันไลบรารีภายในไม่กี่ฟังก์ชันเท่านั้นซึ่งจะเรียกใช้ฟังก์ชันอื่นจนกว่าคุณจะมีระดับความละเอียดในโค้ดของคุณ
Misko

3

ส่วนตัวผมชอบ API ที่:

  1. ได้รับการปรับให้เหมาะสมที่สุดในกรณีที่การใช้งานทั่วไปสามารถทำได้อย่างง่ายดาย
  2. การโทรที่เกี่ยวข้องกับการดำเนินการCRUDเป็นแบบแบตช์หรือมีรุ่นแบตช์
  3. อนุญาตการสะท้อนกลับ (ดังนั้นผู้คนที่เขียนปลั๊กอินหรือการผูกสำหรับภาษาคอมพิวเตอร์อื่น ๆ สามารถทำให้กระบวนการเป็นไปโดยอัตโนมัติได้)
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.