RPC-ish ใกล้จะเหมาะสมกว่า REST เมื่อใด

หลังจากดูการพูดคุยนี้ใน REST แล้ว Reuse and Serendipityโดย Steve Vinoski ฉันสงสัยว่ามีกรณีธุรกิจในโครงการกรีนฟิลด์สำหรับ (XML-) การตั้งค่า RPC-ish ที่ REST ไม่สามารถแก้ไขได้ในทางที่ดีขึ้น

ปัญหา RPC สองสามอย่างที่เขากล่าวถึง:

• มุ่งเน้นที่ภาษา (จัดระบบให้เหมาะสมกับภาษาไม่ใช่วิธีอื่น ๆ )
• "ทำให้ดูเป็นท้องถิ่น" (และรับมือกับความล้มเหลวและความหน่วงแฝงเป็นข้อยกเว้นมากกว่ากฎ)
• ตั้งใจที่จะเป็นภาษาที่เป็นอิสระ แต่ยังคงมี "การเรียกใช้ฟังก์ชัน" ข้ามภาษาเป็นส่วนผสมหลัก
• IDLสำเร็จรูป
• ภาพลวงตาของความปลอดภัยประเภท
• และอีกไม่กี่ ...

เพียงเพิ่มบทละครลงเล็กน้อยผลการค้นหาทันใจของ Google สำหรับ RPC และ REST:

โดยทั่วไป RPC เสนอการรวมภาษามากกว่า REST ดังที่คุณกล่าวถึงสิ่งนี้มาพร้อมกับปัญหาหลายประการในแง่ของขนาดการจัดการข้อผิดพลาดความปลอดภัยของประเภท ฯลฯ โดยเฉพาะอย่างยิ่งเมื่อระบบการแจกจ่ายเดียวเกี่ยวข้องกับโฮสต์หลายเครื่องที่ใช้รหัสที่เขียนในหลายภาษา อย่างไรก็ตามหลังจากเขียนระบบธุรกิจที่ใช้ RPC, REST และแม้ทั้งสองพร้อมกันฉันพบว่ามีเหตุผลที่ดีในการเลือก RPC ผ่าน REST ในบางกรณี

นี่คือกรณีที่ฉันพบว่า RPC เหมาะสมกว่า:

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

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

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

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

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

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

คุณสามารถมีทั้งจริง ปลั๊กอินเช่น RestRPC สำหรับ Grails จะมีคำอธิบายประกอบที่จะตัดการโทรไปยังวิธีการของคุณและจัดการกับมันอย่างสงบในขณะที่ให้คุณมีได้มากเท่าที่คุณต้องการ (ซึ่งคล้ายกับ RPC มาก)