บริการ MVC และ RESTful API

MVC ค่อนข้างตรงไปตรงมา มีรูปแบบตัวควบคุมและมุมมอง เมื่อเราสร้างเว็บไซต์มันทั้งหมดมารวมกันเป็น ' ไคลเอนต์ส่งคำขอคำหลัก REST ไปยังเซิร์ฟเวอร์ -> เซิร์ฟเวอร์ตรงกับ URL ที่ร้องขอไปยังการดำเนินการควบคุม -> ซึ่งจากนั้นเรียกรูปแบบ (s) สำหรับการรวบรวมข้อมูล / การประมวลผลได้รับผล -> และส่งคืนผลลัพธ์กลับไปยังลูกค้าเป็นหน้า HTML (ดู) '

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

MVC เป็นกระบวนทัศน์จากโลก Smalltalk ที่เกี่ยวข้องกับวิธีการที่ระบบปรับทิศทางวัตถุสามารถมี UIs ได้

เฟรมเวิร์กเว็บแรก ๆ นั้นใช้แนวคิดทั่วไป (แยกตรรกะทางธุรกิจออก, ควบคุมตรรกะและดูตรรกะ) และนำหลักการไปใช้กับวิธีที่พวกเขาสร้างเว็บแอปพลิเคชัน ก่อนหน้านี้ไม่ใช่เรื่องแปลกที่พระเจ้าจะสร้างรหัส HTML ในวัตถุโดเมนหรือตรรกะทางธุรกิจในเทมเพลต HTML (คิดว่าเป็น PHP ต้น ๆ )

ประเด็นคือ MVC ดั้งเดิมจากโลก Smalltalk ไม่ใช่สิ่งที่ MVC อยู่ในกรอบงานเว็บส่วนใหญ่ เอาต์พุต HTML ไม่ใช่ "มุมมอง" ในแง่ที่ Smalltalk เข้าใจว่าเป็นหน้าจอ UI

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

ประการที่สอง MVC เป็นเพียงวิธีการสร้างโค้ดฝั่งเซิร์ฟเวอร์ ไม่เกี่ยวข้องกับ REST / HTTP REST เกี่ยวข้องกับวิธีที่ไคลเอ็นต์และเซิร์ฟเวอร์สื่อสารกัน มันไม่สนใจว่าการเป็นตัวแทนของเซิร์ฟเวอร์ที่ส่งไปยังลูกค้านั้นอยู่ในเทมเพลต HTML ที่ใช้เวลามากในการสร้างด้วยเครื่องมือสร้างเท็มเพลตหรือวัตถุ JSON ที่ถูกเรียกครั้งเดียวในคอนโทรลเลอร์

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

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

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

MVC ค่อนข้างตรงไปตรงมา

มาร์ตินฟาวเลอร์อาจจะไม่เห็นด้วยกับสิ่งนี้ :

ผู้คนต่าง ๆ ที่อ่านเกี่ยวกับ MVC ในที่ต่าง ๆ ต่างนำแนวคิดที่แตกต่างกันและอธิบายสิ่งเหล่านี้ว่า 'MVC'

กำลังเดินทางไป...

เมื่อเราสร้างเว็บไซต์มันทั้งหมดมารวมกันเป็น 'ไคลเอนต์ส่งคำขอคำหลัก REST ไปยังเซิร์ฟเวอร์ -> เซิร์ฟเวอร์ตรงกับ URL ที่ร้องขอไปยังการดำเนินการควบคุม -> ซึ่งจากนั้นเรียกรูปแบบ (s) สำหรับการรวบรวมข้อมูล / การประมวลผลได้รับผล -> และส่งคืนผลลัพธ์กลับไปยังลูกค้าเป็นหน้า HTML (ดู) '

ตกลงนี่เป็นเรื่องยุ่งเหยิงนิดหน่อย

MVC ไม่ว่าจะเป็นอะไรคือชุดของแนวคิดสำหรับการนำส่วนติดต่อผู้ใช้ไปใช้

REST เป็นชุดของข้อ จำกัด ทางสถาปัตยกรรมสำหรับการสร้างแอพพลิเคชั่นขนาดใหญ่

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

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

RESTafariansมีความเข้าใจร่วมกันของHATEOAS "ไฮเปอร์เป็นเครื่องมือของรัฐแอพลิเคชัน" และควรจะส่งสัญญาณเตือนเสียงเรียกเข้าผ่านคุณหัว - ทำไมจะมุมมองที่เป็นเครื่องมือของรัฐ ? หากเราตั้งคำถามและมองหาหลักฐานเพิ่มเติมเราอาจสังเกตเห็นสองสิ่งที่แปลก

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

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

แน่นอนว่าคำตอบของปริศนานี้คือ HTML ไม่ใช่มุมมอง คอลเล็กชันของวิดเจ็ตในเบราว์เซอร์เป็นมุมมองและอยู่ในการสื่อสารกับDocument Object Modelซึ่งเริ่มต้นโดยการอ่าน HTML

กล่าวอีกนัยหนึ่ง HTML เป็นตัวแทนของรัฐเช่นเดียวกับRoy T. Fielding ที่สัญญาไว้

ถ้าเรากำลังพูดถึงบริการเว็บ RESTful API ที่บริสุทธิ์ ... เหมือนเมื่อก่อน แต่ไม่มี 'มุมมอง'

ถูกต้องเหมือนเมื่อก่อน: ไม่มีมุมมอง JSON เช่นเดียวกับ HTML เป็นตัวแทนของรัฐเหมาะสำหรับการข้ามขอบเขตกระบวนการ

คิดว่า "DTO" หรือ "ข้อความ" และคุณอ้างถึงจะมีโอกาสน้อยที่จะทำให้คุณหลงทาง

เป็นวิธีที่ควรจะทำอย่างไร

การส่งผ่าน JSON เป็นมุมมองหรือใช้เป็นโมเดลมุมมองเพื่อสร้างมุมมองไม่ละเมิดรูปแบบ

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

หรือมีรูปแบบอื่นที่เหมาะสมกว่าสำหรับบริการ API เท่านั้นแทน MVC หรือไม่

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