REST ได้รับการออกแบบสำหรับเว็บและเว็บได้รับการออกแบบสำหรับ REST ทั้งสองพอดีจะเข้าด้วยกัน วิทยานิพนธ์ระดับปริญญาเอก 2000 วิทยานิพนธ์ของ Roy Fielding รูปแบบสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่ายที่กำหนดและแนะนำคำว่าRESTและมีการทำงานร่วมกันอย่างมีนัยสำคัญระหว่างเว็บและ REST: Roy Fielding ทำงานกับ HTTP / 1.1 ซึ่งเขาเป็นผู้เขียนหลัก และเขาใช้สิ่งที่เขาเรียนรู้ที่นั่นเพื่ออธิบาย REST ในวิทยานิพนธ์ของเขา
ดังนั้นเหตุผลง่ายๆที่เว็บและ REST ทำงานร่วมกันได้ดีก็คือคำจำกัดความของ REST นั้นถูกแยกออกมาจากการทำงานของเว็บและเว็บเป็นการนำ REST มาใช้
นั่นเป็นสาเหตุที่ REST นั้นเหมาะสมสำหรับบริการเว็บและเว็บแอพ: เพราะคุณทำสิ่งเดียวกับที่ได้รับการพิสูจน์แล้วว่าทำงานบนเว็บ "มนุษย์" แล้วนำไปใช้กับเว็บ "เครื่องจักร"
ใหญ่มีปัญหากับ RPC (ขึ้นอยู่กับที่แน่นอนการดำเนินงาน) อยู่โดยทั่วไปในชักนำของการคำนวณแบบกระจายซึ่งมีการอธิบายในรายละเอียดในนี้เอกสารโดย Arnon Rotem-Gal-Oz :
- เครือข่ายมีความน่าเชื่อถือ
- ความหน่วงแฝงเป็นศูนย์
- แบนด์วิดธ์ไม่ จำกัด
- เครือข่ายมีความปลอดภัย
- โทโพโลยีไม่เปลี่ยนแปลง
- มีผู้ดูแลระบบหนึ่งคน
- ค่าขนส่งเป็นศูนย์
- เครือข่ายเป็นเนื้อเดียวกัน
ทั้งหมดนี้เป็นข้อสันนิษฐานที่ผู้มาใหม่มักทำเมื่อเริ่มสร้างระบบแบบกระจาย แน่นอนพวกเขาทั้งหมดเป็นเท็จ และคุณต้องคำนึงถึงสิ่งเหล่านี้ทั้งหมดเมื่อสร้างระบบแบบกระจาย
ปัญหาเกี่ยวกับการใช้งาน RPC จำนวนมากคือพวกเขาพยายามโทรระยะไกลดูเหมือนกับการโทรภายใน แต่มันก็ไม่เหมือนกัน:
- การโทรในประเทศไม่เคยล้มเหลว ย่อยที่คุณเรียกว่าอาจจะล้มเหลว แต่การเรียกตัวเองไม่ได้ทำ - การโทรระยะไกลอาจได้รับหายไปในเครือข่าย
- โทรในประเทศทันที ย่อยที่คุณเรียกว่าสามารถใช้งานเป็นเวลานาน (หรือแม้กระทั่งตลอดไปหากได้รับติดอยู่ในวง จำกัด ) แต่การเรียกตัวเองต้องใช้เวลาที่ทุกคน (ดีกำมือของคำแนะนำของ CPU ที่มากที่สุดน้อยกว่าถ้าโทร inlined แต่เร็วมาก ) - การโทรระยะไกลอาจค้างอยู่บนเครือข่ายเป็นเวลานาน
- หากรูทีนย่อยกลับมาตามปกติผลลัพธ์จะกลับมาเสมอ - ด้วยการโทรระยะไกลผลลัพธ์อาจหายไปบนเครือข่าย
- ผลตอบแทนเป็นแบบทันที - ผลลัพธ์จากระยะไกลสามารถเดินทางบนเครือข่ายเป็นเวลานาน
- ถ้าฉันเรียกรูทีนย่อยหนึ่งครั้งมันจะทำงานอย่างแน่นอนครั้งเดียว - การโทรระยะไกลอาจหายไปในเครือข่ายหรือทำซ้ำดังนั้นรูทีนระยะไกลอาจทำงานระหว่าง 0 ถึงกี่ครั้งก็ได้
- ฉันได้ผลลัพธ์หนึ่งรายการกลับมา - ผลลัพธ์ระยะไกลอาจสูญหายหรือทำซ้ำดังนั้นคุณอาจได้ผลลัพธ์ 0 หรือมากกว่านั้น
- ถ้าฉันเรียกรูทีนย่อยสองครั้งฉันจะได้ผลลัพธ์สองครั้งและฉันจะได้รับผลลัพธ์ของการโทรครั้งแรกก่อนผลลัพธ์ของการโทรครั้งที่สอง - คุณอาจเดาได้ว่าตอนนี้: ด้วย RPC คุณอาจไม่ได้รับผลลัพธ์ใด ๆ หรือเฉพาะที่สองหรือที่สองก่อนที่หนึ่งหรือที่หนึ่งอาจหายไปและคุณได้รับสองครั้งหรือวิธีอื่น ๆ และอื่น ๆ ...
- ถ้าฉันโทร
aแล้วbฉันจะได้ผลลัพธ์กลับมาaและผลลัพธ์ของb - นี่เป็นรุ่นทั่วไปของจุดก่อนหน้านี้มากกว่าด้วย RPC คุณอาจได้คำตอบสองคำตอบ 0 หรือมากกว่านั้นในลำดับใดก็ได้
คุณจะต้องจัดการกับสิ่งทั้งหมดข้างต้นสำหรับการโทรระยะไกล แต่ถ้าคุณจะทำให้กรอบการโทรทางไกลแยกไม่ออกจากโทรศัพท์ในพื้นที่แล้วคุณไม่สามารถเพราะคุณไม่ทราบว่าคนที่เป็นสายระยะไกล เฟรมเวิร์กอาจลองและจัดการสิ่งเหล่านี้ให้คุณ แต่ปัญหาคือ: เฟรมเวิร์กไม่ทราบมากเกี่ยวกับระบบของคุณเท่าที่คุณทำ ไม่ทราบว่ามีการโทรที่จริง ๆ แล้วมันไม่สำคัญว่าใครจะหายไปนาน ๆ ดังนั้นกรอบจะต้องมีการป้องกันมากและมีราคาแพงในแง่ของความล่าช้าและแบนด์วิดธ์
โดยเฉพาะอย่างยิ่งเนื่องจากกรอบงานไม่สามารถป้องกันคุณได้ CAP ทฤษฎีบทบอกว่าระบบกระจายไม่สามารถที่สอดคล้องกัน, มีและ Partition ทนในเวลาเดียวกัน; มันบอกว่าเมื่อพาร์ติชั่นเกิดขึ้นระบบจะไม่สามารถดำเนินต่อไปได้ทั้งแบบต่อเนื่องและพร้อมใช้งานมันต้องเลือกอย่างใดอย่างหนึ่ง (ตรงกันข้ามกับความเชื่อที่นิยมทฤษฎีบทไม่ได้บอกว่าคุณไม่สามารถมีทั้งสามอย่างได้) โดยปกติคุณสามารถมีทั้งสามได้ แต่เมื่อคุณมีพาร์ติชั่นคุณจะต้องเลือกหนึ่งในสองอันนั้น) PACELC ทฤษฎีบทขยาย CAP ทฤษฎีบทโดยแสดงให้เห็นว่าแม้ในขณะที่ระบบมีการทำงานที่คุณต้องการปิดแฝงกับความสอดคล้อง
สิ่งเหล่านี้เป็นการแลกเปลี่ยนที่สำคัญที่เฟรมเวิร์กไม่สามารถป้องกันคุณได้เนื่องจากเป็นโดเมนเฉพาะและสำคัญต่อการออกแบบหลัก
คมชัดนี้ด้วยวิธีการเช่น Erlang ซึ่งไม่ทำงาน: ใน Erlang, ทุกข้อความส่งจะถือว่าเป็นระยะไกลถึงแม้ว่าพวกเขามีในท้องถิ่น ซึ่งหมายความว่าคุณพร้อมที่จะรับมือกับปัญหาข้างต้นทั้งหมด (และอีกมากมาย) สำหรับกระบวนการในท้องถิ่นสิ่งเหล่านี้จะก่อให้เกิดค่าใช้จ่ายเล็กน้อย เพื่อช่วยในเรื่องนี้มีเครื่องมือกรอบงานห้องสมุดรูปแบบและสำนวนที่ใช้จัดการกับข้อผิดพลาดและการกำกับดูแล
คุณยังไม่ได้อธิบายวิธีการทำงานของกรอบ RPC ของคุณโดยเฉพาะและภาษาหรือไลบรารีที่คุณใช้ แต่ฉันมีข้อสงสัยอย่างมากว่ามันเป็นของประเภท "แกล้งเครือข่ายที่ไม่มีอยู่" ในอดีต สิ่งเหล่านั้นไม่ทำงาน มันก็โอเคที่จะลบความแตกต่างระหว่างการโทรในพื้นที่และระยะไกลโดยการจัดการทุกอย่างเป็นการโทรระยะไกล การทำอย่างอื่นรอบบทคัดย่อมากเกินไป: เครือข่ายเป็นส่วนหนึ่งของระบบของคุณหากคุณทำให้เป็นนามธรรมคุณจะทำให้บางสิ่งที่คุณจำเป็นต้องรู้
ตอนนี้ไม่ว่าคุณจะต้องใช้ REST โดยเฉพาะหรือไม่นั่นเป็นคำถามที่แตกต่างอย่างสิ้นเชิง ขณะที่ผมอธิบายไว้ข้างต้นเว็บได้รับการออกแบบเพื่อการพักผ่อนและส่วนที่เหลือได้รับการออกแบบสำหรับเว็บดังนั้นทั้งสองทำทำให้ความรู้สึกร่วมกัน แต่คุณสามารถใช้รูปแบบสถาปัตยกรรมอื่น ๆ ถ้าคุณต้องการที่จะ แต่อย่างน้อยคำถามของคุณเกี่ยวกับ "ทำไมไม่ใช่ RPC" และฉันได้อธิบายเหตุผลข้างต้นฉันอธิบายได้อย่างแม่นยำมากขึ้นว่าทำไมประเภทของ RPC ที่ฉันสงสัยว่าคุณใช้อาจทำให้คุณเดือดร้อน