คุณควรเขียน back-end ของคุณเป็น API หรือไม่?

วันนี้ฉันมีการสนทนาที่ร้อนแรงเกี่ยวกับแอปพลิเคชัน MVC ของเรา เรามีเว็บไซต์ที่เขียนใน MVC ( ASP.NET ) และโดยปกติจะเป็นไปตามรูปแบบของการทำอะไรบางอย่างในมุมมอง -> กดคอนโทรลเลอร์ -> คอนโทรลเลอร์สร้างโมเดล (เรียกผู้จัดการที่รับข้อมูลสร้างโมเดลใน วิธีการควบคุมเอง) -> โมเดลไปที่ดู -> ล้างและทำซ้ำ

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

วิธีแก้ปัญหาและแนวทางปฏิบัติที่ดีที่สุดที่เขากล่าวคือสร้าง API จากนั้นสร้างเว็บไซต์ของคุณบน API ของคุณจากนั้นสร้างแอปพลิเคชันเดสก์ท็อปแอพมือถือและอื่น ๆ นั้นง่ายมาก

ดูเหมือนว่าเป็นความคิดที่ไม่ดีสำหรับฉันด้วยเหตุผลหลายประการ

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

เหตุผลบางอย่างที่ฉันคิดว่ามันเป็นความคิดที่ไม่ดี:

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

• ทุกสิ่งที่สร้างขึ้นใน MVC ดูเหมือนไร้ประโยชน์เช่นบทบาทและการรับรองความถูกต้อง ตัวอย่างเช่น [อนุญาต] คุณสมบัติและความปลอดภัย; คุณจะต้องม้วนตัวเอง

• การเรียก API ทั้งหมดของคุณจะต้องมีข้อมูลความปลอดภัยแนบมาและคุณจะต้องพัฒนาระบบโทเค็นและอะไรก็ตาม

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

• คุณสูญเสียเครื่องมือทุกชนิดเช่นอินเทอร์เฟซและคลาสนามธรรมเมื่อพูดถึง API สิ่งต่าง ๆ เช่นWCFได้รับการสนับสนุนอย่างมากสำหรับอินเตอร์เฟส

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

• YAGNI นอกจากว่าคุณกำลังวางแผนที่จะเขียนแอพพลิเคชั่นที่ทำงานเหมือนกันสองแอปพลิเคชั่นหนึ่งเว็บและแอพพลิเคชั่น Windows หนึ่งแอปพลิเคชันมันเป็นงานพัฒนาพิเศษจำนวนมาก

• การแก้จุดบกพร่องนั้นยากกว่ามากเมื่อคุณไม่สามารถก้าวจากต้นจนจบ

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

• อาจมีสาเหตุเพิ่มเติมบางอย่างเหล่านี้เป็นเพียงด้านบนของหัวของฉัน

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

แก้ไข: คำตอบที่ยอดเยี่ยมเริ่มต้นจากการได้รับแนวคิดที่ดีว่าสิ่งนี้หมายความว่าอย่างไร เพื่อขยายคำถามของฉันคุณจะจัดโครงสร้างแอป MVC เพื่อติดตามโครงสร้าง API นี้อย่างไร

ตัวอย่างเช่นคุณมีเว็บไซต์ที่แสดงข้อมูลเกี่ยวกับผู้ใช้ ภายใต้ MVC คุณมี:

มุมมอง - (CS) HTML เพจที่แสดงตัวควบคุม UserViewModel - เรียกใช้ GetUser () และสร้าง UserViewModel ที่ส่งผ่านไปยังคลาส view Manager (เรียงลำดับ API ของคุณ) ที่มีเมธอด GetUser

คอนโทรลเลอร์ใช้ GetUser () แต่คุณต้องการแอพเดสก์ท็อปด้วย นี่หมายความว่า GetUser ของคุณต้องได้รับการเปิดเผยผ่าน API บางประเภท คุณอาจต้องการการเชื่อมต่อ TCP, WCF หรือ Remoting คุณต้องการแอพมือถือที่จะสงบเนื่องจากการเชื่อมต่อแบบไม่ต่อเนื่องไม่สม่ำเสมอ

ดังนั้นคุณจะเขียน API สำหรับแต่ละบริการเว็บ WCF ที่มีวิธี GetUser () และรหัสเพียงreturn new UserManager().GetUser()? และวิธี mvc 4 web api ที่ทำสิ่งเดียวกัน? ในขณะที่โทรหา GetUser ต่อไปโดยตรงในวิธีการควบคุม MVC ของคุณ

หรือคุณจะเลือกโซลูชันที่เหมาะกับทั้งสาม (บริการ web api REST) ​​และสร้างทุกอย่างในนั้นดังนั้นแอปทั้งสามจึงทำการเรียก API (ตัว mvc ไปยังเครื่องท้องถิ่น)

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

แก้ไข 2: หลังจากอ่านเนื้อหาเพิ่มเติมฉันได้ใส่ความคิดเห็นไว้ด้านล่างซึ่งฉันคิดว่าอาจอธิบายได้ คำถามนี้เป็นคำถามหลอกลวงที่ฉันคิดว่า หากคุณเขียน back-end ของคุณเนื่องจาก API ทำให้ฉันสับสนคิดว่าควรมีบริการเว็บเดียวที่ทุกอย่าง (แอพ mvc, แอพเดสก์ท็อป, แอพมือถือ) โทรทำสิ่งต่างๆ

ข้อสรุปที่ฉันได้มาคือสิ่งที่คุณควรทำจริงๆคือตรวจสอบให้แน่ใจว่าเลเยอร์ตรรกะทางธุรกิจของคุณถูกแยกออกอย่างถูกต้อง เมื่อดูที่รหัสของฉันฉันทำสิ่งนี้ไปแล้ว - ผู้ควบคุมจะโทรหาGetUser()ผู้จัดการจากนั้นสร้างโมเดลมุมมองจากมันเพื่อแสดงผลด้วยมุมมอง ดังนั้นชั้นตรรกะทางธุรกิจคือ API หากคุณต้องการโทรจากแอพเดสก์ท็อปคุณจะต้องเขียนบางอย่างเช่นบริการ WCF เพื่ออำนวยความสะดวกในการโทร แม้เพียงแค่มีวิธี WCF เรียกว่าGetUser()ที่มีรหัสreturn MyBusinessLayer.GetUser()จะเพียงพอ ดังนั้น API จึงเป็นตรรกะทางธุรกิจและ WCF / web api เป็นต้นเป็นเพียงส่วนหนึ่งของรหัสเพื่อให้แอปพลิเคชันภายนอกเรียกมันได้

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

หวังว่าการตีความนี้ถูกต้อง ขอบคุณสำหรับการอภิปราย / ความคิดเห็นทั้งหมดที่ได้สร้างขึ้น

ใช่คุณควรจะ.

มันไม่เพียงทำให้ back-end ของคุณสามารถใช้งานได้อีกต่อไป แต่ยังช่วยเพิ่มความปลอดภัยและการออกแบบที่ดีขึ้น หากคุณเขียนแบ็กเอนด์ของคุณเป็นส่วนหนึ่งของระบบเดียวคุณกำลังออกแบบเสาหินที่ไม่สามารถขยายเปลี่ยนหรือปรับปรุงได้อย่างง่ายดาย

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

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

แก้ไข:ตกลงฉันเห็นปัญหาของคุณ คุณคิดว่า API เป็นห้องสมุดระยะไกล มันไม่ใช่. คิดว่าการบริการเป็นมากกว่าการให้บริการข้อมูล คุณเรียกใช้บริการเพื่อรับข้อมูลจากนั้นดำเนินการกับข้อมูลนั้นในเครื่อง เพื่อตรวจสอบว่าผู้ใช้เข้าสู่ระบบคุณจะเรียก " GetUser" แล้วดู'logged on'ค่าเช่น ( YMMVพร้อมตัวอย่างนั้นแน่นอน)

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

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

การดีบักนั้นง่ายเกินไป - คุณสามารถทดสอบ API อย่างแยกได้อย่างละเอียดดังนั้นคุณไม่จำเป็นต้องทำการดีบัก (และคุณสามารถดีบักแบบครบวงจร Visual Studio สามารถแนบกับกระบวนการหลายอย่างพร้อมกันได้)

สิ่งต่าง ๆ เช่นงานพิเศษที่ใช้ความปลอดภัยเป็นสิ่งที่ดี ในปัจจุบันหากคุณรวมรหัสทั้งหมดไว้ในเว็บไซต์ของคุณหากแฮกเกอร์สามารถเข้าถึงได้พวกเขายังสามารถเข้าถึงทุกสิ่งได้ด้วย DB รวมอยู่ด้วย ถ้าคุณแยกมันออกเป็น API แฮ็กเกอร์สามารถทำอะไรกับโค้ดของคุณได้น้อยมากเว้นแต่พวกเขาจะแฮ็คเลเยอร์ API ด้วยซึ่งจะเป็นเรื่องที่เหลือเชื่อสำหรับพวกเขา (เคยสงสัยหรือไม่ว่า พวกเขาแฮ็คระบบปฏิบัติการหรือเว็บเซิร์ฟเวอร์และมีการเชื่อมต่อโดยตรงกับฐานข้อมูลที่สามารถเรียกใช้ได้select * from usersอย่างง่ายดาย" "

ฉันจะบอกว่าฉันได้เห็นเว็บไซต์จำนวนมาก (และแอปพลิเคชันไคลเอนต์เซิร์ฟเวอร์) ที่เขียนเช่นนี้ เมื่อฉันทำงานในอุตสาหกรรมบริการทางการเงินไม่มีใครเคยเขียนเว็บไซต์ all-in-one เพราะมันมีความเสี่ยงด้านความปลอดภัยมากเกินไปและส่วนหนึ่งเป็นเพราะการพัฒนาส่วนใหญ่เป็น GUIs ที่เสถียรมากกว่าการประมวลผลข้อมูลแบ็คเอนด์ที่เสถียร ระบบ ง่ายที่จะเปิดเผยระบบ DP เป็นเว็บไซต์ที่ใช้สถาปัตยกรรมสไตล์บริการ

2nd แก้ไข:ลิงค์บางเรื่องใน (สำหรับ OP):

โปรดทราบว่าเมื่อพูดถึงสิ่งเหล่านี้ในบริบทของเว็บไซต์เว็บเซิร์ฟเวอร์ควรพิจารณาเลเยอร์การนำเสนอเพราะเป็นไคลเอนต์ที่เรียกชั้นอื่น ๆ และเพราะมันสร้างมุมมอง UI ที่ถูกส่งไปยังเบราว์เซอร์สำหรับการแสดงผล มันเป็นเรื่องใหญ่และมีหลายวิธีในการออกแบบแอปพลิเคชันของคุณ - data-centric หรือ domain-centric (โดยทั่วไปแล้วฉันจะถือว่า domain centric เป็น 'purer' แต่YMMV ) แต่ทุกอย่างลงมาเพื่อผสานระดับตรรกะระหว่าง ลูกค้าและฐานข้อมูลของคุณ มันเหมือนกับ MVC เล็กน้อยถ้าคุณพิจารณาตรงกลาง, API, ระดับที่เทียบเท่ากับโมเดลของคุณเฉพาะรุ่นที่ไม่ได้เป็น wrapper อย่างง่ายสำหรับ DB มันสมบูรณ์ยิ่งขึ้นและสามารถทำได้มากขึ้น (เช่นข้อมูลรวมจากแหล่งข้อมูล 2 แห่งโพสต์ - ประมวลผลข้อมูลให้พอดีกับ API แคชข้อมูล ฯลฯ ):

• สถาปัตยกรรมแบบหลายเทียร์
• การสร้างแอปพลิเคชัน N-Tier ใน. NET
• บทช่วยสอนของ Youtube - ดูลิงก์ที่เกี่ยวข้องด้วยรวมถึงสิ่งที่ต้องทำใน C #
• หลักสูตรการฝึกอบรมแบบหลายคน (ทดลองใช้ฟรีหรือจ่ายเงิน

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

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

อย่างไรก็ตามสิ่งนี้นำมาซึ่งความกังวลบางอย่างตามที่คุณชี้ให้เห็น เพื่อที่อยู่พวกเขา:

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

ขึ้นอยู่กับว่าคุณทำมันอย่างไร ดังที่George Pólyaชี้ให้เห็นในข้อความที่ยอดเยี่ยมของเขาว่าจะแก้ไขได้อย่างไรบ่อยครั้ง "ปัญหาทั่วไปที่อาจแก้ไขได้ง่ายกว่า" นี้เรียกว่านักประดิษฐ์ Paradox ในกรณีของการเขียนโปรแกรมมันมักจะทำงานด้วยการแยกข้อกังวล: แบ็กเอนด์ของคุณไม่ต้องกังวลกับรูปแบบของข้อมูลที่มันใส่เข้าและออกและรหัสของมันจะง่ายขึ้นมาก ตัวแยกวิเคราะห์ข้อมูลและตัวเรนเดอร์ของคุณไม่ต้องกังวลอีกต่อไปว่าเกิดอะไรขึ้นกับข้อมูลที่พวกเขาสร้างดังนั้นพวกเขาก็สามารถทำได้ง่ายขึ้นเช่นกัน ทุกอย่างทำงานได้โดยการทำลายโค้ดให้เป็นกลุ่มที่จัดการได้ง่ายขึ้น

ทุกสิ่งที่สร้างขึ้นใน MVC ดูเหมือนไร้ประโยชน์เช่นบทบาทและการรับรองความถูกต้อง ตัวอย่างเช่น [อนุญาต] คุณสมบัติและความปลอดภัย; คุณจะต้องม้วนตัวเอง

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

พิจารณาLinus Torvaldsผู้มีชื่อเสียงมากที่สุดในการเขียนLinuxแต่ใครยังเขียนgit : ตอนนี้หนึ่งในระบบควบคุมเวอร์ชันยอดนิยมที่สุดในโลก หนึ่งในปัจจัยผลักดันในการออกแบบของเขาคือการต่อต้านการโค่นล้ม (อีกVCS ที่นิยมอย่างมากและเนื้อหาที่ได้รับความนิยมมากที่สุดในขณะที่เขียนคอมไพล์); เขาตัดสินใจที่จะใช้ทุกสิ่งที่การโค่นล้มได้และไม่ว่าจะเป็นไปได้อย่างไรให้แก้ปัญหาเหล่านั้นให้แตกต่างกัน ในการทำเช่นนี้เขาจะต้องเป็นผู้เชี่ยวชาญในการโค่นล้มในสิทธิของตนเองอย่างแม่นยำเพื่อให้เขาสามารถเข้าใจโดเมนปัญหาเดียวกันและใช้แนวทางที่แตกต่างกัน

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

การเรียก API ทั้งหมดของคุณจะต้องมีข้อมูลความปลอดภัยแนบมาและคุณจะต้องพัฒนาระบบโทเค็นและอะไรก็ตาม

ใช่. นี่คือวิธีที่ควรจะเป็น

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

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

คุณสูญเสียเครื่องมือทุกชนิดเช่นอินเทอร์เฟซและคลาสนามธรรมเมื่อพูดถึง API สิ่งต่าง ๆ เช่น WCF ได้รับการสนับสนุนอย่างมากสำหรับอินเทอร์เฟซ

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

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

การสร้างวิธีที่มีอยู่เป็นจำนวนมากเป็นสิ่งที่ฉันเรียกว่า "ทำงานได้มากกว่านี้" หากคุณไม่ได้กังวลเกี่ยวกับสิ่งต่าง ๆ เช่นอะตอมมิกซิตี้วิธีการแบบกลุ่มสามารถปิดท้ายได้ไม่มากไปกว่าส่วนหน้าบางที่เป็นต้นฉบับ

YAGNI นอกจากว่าคุณกำลังวางแผนที่จะเขียนแอพพลิเคชั่นที่ทำงานเหมือนกันสองแอปพลิเคชั่นหนึ่งเว็บและแอพพลิเคชั่น Windows หนึ่งแอปพลิเคชันมันเป็นงานพัฒนาพิเศษจำนวนมาก

ไม่ YANI (คุณต้องการมันแล้ว) ฉันระบุไว้ข้างต้น คำถามเดียวคือจำนวนงานออกแบบที่จะใส่เข้าไป

การแก้จุดบกพร่องนั้นยากกว่ามากเมื่อคุณไม่สามารถก้าวจากต้นจนจบ

ทำไมคุณไม่สามารถก้าวผ่านแบบ end-to-end ได้?

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

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

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

ในบางวิธีสิ่งนี้ไม่เหมือนกับสถาปัตยกรรมRISCที่ด้านฮาร์ดแวร์ หนึ่งในความแตกต่างที่สำคัญระหว่าง RISC และCISC (รุ่นก่อน) คือสถาปัตยกรรม CISC มีแนวโน้มที่จะรวมคำแนะนำมากมายที่ทำงานโดยตรงบนหน่วยความจำในขณะที่สถาปัตยกรรม RISC มักจะทำงานส่วนใหญ่ในการลงทะเบียน: ในสถาปัตยกรรม RISC ล้วนๆ โหลด (คัดลอกบางสิ่งจากหน่วยความจำไปยังรีจิสเตอร์) และสโตร์ (รับค่าจากรีจิสเตอร์และใส่ลงในหน่วยความจำ)

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

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

อ่านเพิ่มเติม:

1. การออกแบบ REST API - การสร้างแบบจำลองทรัพยากร

ฉันรู้ว่า microservices เป็นความโกรธในขณะนี้ แต่พวกเขาก็ไม่คุ้มค่าเสมอไป ใช่รหัสคู่ที่หลวมเป็นเป้าหมาย แต่มันก็ไม่ควรที่จะเสียค่าใช้จ่ายจากวงจรการพัฒนาที่เจ็บปวดกว่านี้

จุดศูนย์กลางที่ดีคือการสร้างโครงการข้อมูลแยกต่างหากในโซลูชันของคุณ โครงการข้อมูลจะเป็น. NET class library โครงการ ASP.NET MVC ของคุณจะเพิ่มการอ้างอิงไปยังไลบรารีข้อมูลและทุกรุ่นจะถูกดึงจากโครงการข้อมูล จากนั้นเมื่อถึงเวลาสร้างเดสก์ท็อปหรือแอพมือถือคุณสามารถอ้างอิงรหัสเดียวกันได้ ดังนั้นจึงอาจไม่ใช่ API อย่างเป็นทางการ แต่จะทำงานเป็นหนึ่งเดียว หากคุณต้องการให้สามารถเข้าถึงได้ในฐานะ API คุณสามารถสร้างโครงการเว็บอย่างง่ายที่ทำหน้าที่เป็น wrapper ในโครงการข้อมูล

ไมโครซอฟท์ได้รับการส่งเสริมแนวคิดนี้ซึ่งพวกเขาเรียกClass ห้องสมุดแบบพกพา

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

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

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

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

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

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

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

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

ขึ้นอยู่กับประเภทของแอปพลิเคชันและประเภทของตลาดที่คุณใช้

มีการแลกเปลี่ยนและผลประโยชน์กับวิธีนี้ ไม่ใช่คำตอบที่ชัดเจนว่าวิธีหนึ่งดีกว่าอีกวิธีหนึ่ง

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

ประโยชน์ที่ได้รับ

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

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

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

ไม่ชอบการค้า

• มีความยืดหยุ่น คุณต้องทำงานเพื่อ "สร้าง" สิ่งที่ดีให้กับ API ไม่สามารถเรียกใช้แบบสอบถาม DB อย่างรวดเร็วจากภายในรหัส UI เพื่อแก้ปัญหาเฉพาะ นอกจากนี้ API ที่นำกลับมาใช้ซ้ำได้นั้นต้องคำนึงถึงกรณีการใช้งานจำนวนมากด้วยว่าวิธีแก้ปัญหาอย่างรวดเร็วนั้นมักจะเป็นทางออกที่ผิด API มีความยืดหยุ่นน้อยลงในการพัฒนาโดยเฉพาะอย่างยิ่งเนื่องจากมีรหัสลูกค้าจำนวนมากอยู่แล้ว (เรากำลังเปลี่ยนไปใช้ API ที่มีเวอร์ชันด้วยเหตุผลนั้น)

• ความเร็วการพัฒนาเริ่มต้น มันช้ากว่าในการพัฒนา API ก่อนโดยไม่ต้องสงสัยเลย คุณจะชนะได้ก็ต่อเมื่อคุณมีลูกค้าเพียงพอที่สร้างอยู่ด้านบนของ API แต่คุณจะพบว่าคุณต้องการการใช้งานไคลเอนต์ที่แตกต่างกัน 3 ตัวก่อนที่ API ของคุณจะได้รับการพัฒนาให้เพียงพอ เราพบว่าการออกแบบ API เริ่มต้นส่วนใหญ่ของเราผิดและต้องแก้ไขหลักเกณฑ์ของเราอย่างเข้มงวดสำหรับวิธีการสร้างบริการเว็บ

ปลาเฮอริ่งแดง

คุณพูดถึงสิ่งเหล่านี้ พวกเขาไม่ได้มีความสำคัญในทางปฏิบัติ

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

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

• การดำเนินงานเป็นกลุ่ม โดยทั่วไปแล้วจะแก้ไขได้ด้วยการสร้าง API จำนวนมากซึ่งเรียกใช้งานแบ็คเอนด์และส่งคืน id งานสำหรับการสอบถามสถานะ มันไม่ใช่เรื่องใหญ่อะไร

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

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

สรุป

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

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

มีประโยชน์ที่สำคัญบางอย่างสำหรับ SOA ซึ่งฉันจะพยายามระบุ:

scalability

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

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

การตรวจสอบได้

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

API หลีกเลี่ยงปัญหานี้ การเรียก API แต่ละครั้งจะดึงทรัพยากรและให้บริการ สะอาดและทดสอบได้

รับประกันการแยกความกังวล

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

ข้อเสีย

แน่นอนว่ามีข้อเสียอยู่บ้าง เสาหินมักจะเร็วกว่าที่จะไปด้วย อาจเป็นสิ่งที่คุณคุ้นเคย มันอาจเข้ากับกองของคุณได้ดีกว่า เครื่องมือของคุณอาจเหมาะสำหรับการสร้างเสาหิน

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

มีคำตอบที่ดีที่นี่ดังนั้นฉันจะเพิ่มประสบการณ์การใช้งานของฉัน

นี่คือสิ่งที่ฉันทำ:

• สร้างเลเยอร์การเข้าถึงฐานข้อมูลที่จัดการทั้งหมด / เพียงปฏิสัมพันธ์ DB (ปกติคู่มือ SQL จะใช้สำหรับความเร็วและการควบคุมไม่มีการออม) แทรกอัปเดตลบเลือก ...
• สร้างinterface( virtual class) ที่แสดง / บังคับใช้ฟังก์ชัน API ที่ฉันต้องการ เมื่อนำไปใช้จะใช้ฟังก์ชัน DBAL ที่มีความเชี่ยวชาญสูงเพื่อให้ได้ผลลัพธ์ นอกจากนี้ยังช่วยให้ฉันบังคับใช้ API ในระดับคอมไพเลอร์ดังนั้นฉันจึงมั่นใจได้ว่าการติดตั้งเซิร์ฟเวอร์ + API มีฟังก์ชั่นทั้งหมดในตัว
• สร้างเลเยอร์ที่สองที่ใช้อินเทอร์เฟซ(นี่คือ API จริง)และบังคับใช้ข้อ จำกัด ด้านความปลอดภัย คุณสามารถโต้ตอบกับ API ภายนอกได้ที่นี่
• เว็บไซต์จะใช้ชั้นที่สองโดยตรง(สำหรับผลการดำเนินงาน)โดยไม่ต้องไปแม้ว่าระยะไกลสามารถเข้าถึง API (เช่นสบู่, JSON)
• แบบสแตนด์อโลน Server เป็นสร้างที่ใช้อินเตอร์เฟซและตีแผ่ชั้นที่สองเป็นจริง API ระยะไกลที่สามารถเข้าถึงเดสก์ทอปภายนอก / ลูกค้ามือถือ(การเข้าถึงที่ไม่ใช่เว็บไซต์) สิ่งที่มันทำคือถอดรหัสคำขอและเข้ารหัสการตอบสนองและจัดการ / ยกเลิกการเชื่อมต่อกับไคลเอ็นต์ นอกจากนี้ยังสนับสนุนความสามารถในการส่งเรื่องกลับไปยังมวลแจ้งให้ลูกค้าของเหตุการณ์ที่เกิดขึ้นจากเพื่อนร่วมงานที่เชื่อมต่ออื่น ๆ(การทำงานที่เว็บไซต์ไม่ได้มักจะต้องใช้)

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

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

PS : ใช่การบำรุงรักษานั้นซับซ้อนกว่าเล็กน้อยเนื่องจากล้อทำงานร่วมกันมากขึ้น แต่จะง่ายขึ้นในระยะยาว ดังนั้นหากโครงการของคุณตั้งใจจะมีชีวิตอยู่ชั่วขณะหนึ่งและมีความซับซ้อนเล็กน้อยให้ใช้ API เสมอ นอกจากนี้ยังง่ายกว่ามากในการทดสอบแต่ละชั้นด้วยตนเอง

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

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

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

ตัวอย่าง

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

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

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

คุณล่ะ ถ้าไม่เช่นนั้นนั่นเป็นข้อความที่ไม่เกี่ยวข้องเลย

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

แต่ถ้าคุณมีเว็บไซต์ที่มีอยู่แล้วและไม่มีแผนที่จะมีอินเทอร์เฟซต่าง ๆ มากมาย (เท่าที่ฉันจะบอกได้) ความคิดเห็นของเขาก็ไม่เกี่ยวข้องเลย

เวอร์ชั่นสั้น: API ของคุณมีประสิทธิภาพไม่ว่าจะเป็นอะไร แม้ว่า ASP.NET อาจจะคลุมเครือ

รุ่นที่ยาวกว่า:

ลองนึกถึง MVC Web App พื้นฐานที่ให้ข้อมูลเกี่ยวกับเบียร์และขายให้คุณ เส้นทางมีลักษณะอย่างไร

/sign_in
/sign_out
/beer
/beer/{beer_name}
/order
/order/{order_number}

ในแอปพลิเคชันเว็บปกติมีเส้นทางบางเส้นทางเช่น:

/beer/new
/beer/{beer_name}/edit
/beer/{beer_name}/delete
/order/new
/order/{order_number}/edit
/order/{order_number}/delete

ใน Web API นั้นไม่จำเป็นเพราะมันถูกอนุมานจากวิธี HTTP

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

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

หากคุณใช้ MVC 6 คุณจะได้รับทั้งในคลาสคอนโทรลเลอร์แบบรวมที่สามารถฉลาดเกี่ยวกับสิ่งที่มันกลับมา ฉันไม่พบโค้ดตัวอย่าง ASP ที่ดีสำหรับรุ่นนี้ แต่ฉันพบโค้ด Rails บางตัวที่มีรูปแบบเดียวกัน พิจารณาตัวควบคุมนี้สำหรับ "ไลค์" จากโครงการ Diaspora เมธอดคอนโทรลเลอร์แต่ละตัวมีเส้นทางที่กำหนดโดย "แบบแผน resourceful" ที่นี่ซึ่งมีจำนวน LCRUD ใน API

หากคุณอ่านการใช้งานแต่ละอย่างอาจตอบสนองต่อ HTML, Mobile HTML หรือ JSON สิ่งนี้รวมกับแบบแผนสำหรับการค้นหามุมมองทำให้เว็บแอปและเว็บ API รวมกันอย่างสมบูรณ์ นอกจากนี้คุณยังจะทราบว่าไม่ใช่วิธีการทั้งหมดที่ให้การตอบกลับแต่ละอัน (ซึ่งสมเหตุสมผลเนื่องจาก UI อาจต้องใช้วิธีการที่ API ใช้ไม่ได้

นี่เป็นอิมพิแดนซ์ที่ไม่ตรงกันเนื่องจาก ASP.NET คิดว่าทั้งหมดนี้มาสายในขณะที่ Rails ได้ใช้สมมาตรมาระยะหนึ่งแล้วทำให้ชัดเจน

เก็งกำไร:

ผู้ร่วมงานของคุณอาจถูกและผิดขึ้นอยู่กับเวอร์ชันของ ASP ที่คุณใช้ ภายใต้ MVC เวอร์ชันเก่าความแตกต่างระหว่าง API และ App อาจทำให้เป็น "แนวปฏิบัติที่ดีที่สุด" ในการสร้าง API ล่วงหน้าเพราะโมเดลของ ASP.NET ไม่อนุญาตให้นำรหัสที่ดีมาใช้ซ้ำได้จริง

ด้วยรหัสที่ใหม่กว่าจะทำให้การใช้รหัสรวมเป็นเรื่องที่ง่ายขึ้นเนื่องจากเป็นการง่ายต่อการใช้รหัสอีกครั้งด้วยคลาสพื้นฐานของตัวควบคุมแบบรวม

อย่างไรก็ตามในกรณีใดก็ตามคอนโทรลเลอร์เป็น API ที่มีประสิทธิภาพ

เมื่อฉันเริ่มอาชีพของฉันในปี 2549 สถาปัตยกรรมประเภทนี้เป็นความเดือดดาลในโลก NET ฉันทำงานใน 3 โครงการที่แยกจากกันในช่วงกลางปี ​​2000 ด้วยบริการเว็บระหว่างชั้นตรรกะทางธุรกิจและส่วนหน้าของเว็บ แน่นอนวันนี้บริการเว็บเป็นสบู่ แต่ก็ยังคงสถาปัตยกรรมเดียวกัน ประโยชน์ที่ได้รับคือความสามารถในการสลับไปข้างหน้าหรือแบ็กเอนด์และแม้กระทั่งการพัฒนาโปรแกรมเดสก์ทอป ในที่สุด YAGNI พิสูจน์แล้วว่าเป็นจริง ฉันไม่เคยเห็นสิ่งนี้เกิดขึ้นเลย ตลอดเวลาที่ฉันเห็นค่าใช้จ่ายในการแยกโครงการด้วยวิธีนี้ ฉันได้รับการฉีกขาดบริการเว็บจากหนึ่งในโครงการ (ใช้เวลาครึ่งปีในการลบทีละขั้นตอนในขณะที่ทำสิ่งอื่น ๆ ) และทีมงานทั้งหมดก็มีความสุข ฉันไม่เคยลองวิธีการนั้นมาก่อนและฉันจะไม่ยอมให้ด้วยเหตุผลที่เฉพาะเจาะจง ประสบการณ์ 5 ปีที่พยายามสถาปัตยกรรมนี้สอนฉันว่าฉันไม่ต้องการมันและไม่มีผู้เชี่ยวชาญจำนวนมากที่บอกฉันว่าสิ่งที่ตรงกันข้ามจะทำให้ฉันเชื่อว่าฉันจะทำ เฉพาะโครงการที่ฉันต้องการอาจทำได้

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

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

บุคคลที่สามจะใช้หรือไม่ ใช่คุณควร

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

คุณกำลังรีบ? ไม่คุณไม่ควร
การปรับโครงสร้างภายหลังนั้นง่ายกว่าและเร็วกว่าวิธีการส่วนใหญ่และครูคาดเดาและบอกได้ การมีสิ่งที่ใช้งานได้ดีกว่านั้นเป็นสิ่งสำคัญ (ถึงแม้จะมีการออกแบบภายในที่ไม่ดีเท่าที่จะทำได้และจะได้รับการปรับโครงสร้างใหม่) แทนที่จะไม่มีสิ่งใดเลย (แต่ด้วยการออกแบบภายในที่เหลือเชื่อ wohoo)

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

มีคำตอบที่ดีอยู่ที่นี่ ฉันโพสต์สิ่งนี้เป็นคำตอบบางส่วน; มันอาจจะดีกว่าเป็นความคิดเห็น อย่างไรก็ตามการแสดงความคิดเห็นแบบเดียวกันกับโพสต์มากมายนั้นไม่ดี

ไม่มีใครสามารถอ้างสิทธิ์ YAGNI ได้ด้วยเหตุผลที่ไม่ได้สร้าง API

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

API ยังช่วยป้องกันไม่ให้ตัวแปลงสัญญาณ Front-end จากข้อกังวลของตัวแปลงสัญญาณส่วนท้ายและในทางกลับกัน นี่เป็นทักษะที่แตกต่างกันมากใน บริษัท ของเรา API ช่วยให้เราสามารถมุ่งเน้นที่ที่เราแข็งแกร่งที่สุด