REST กับ JSON-RPC? [ปิด]

ฉันพยายามเลือกระหว่าง REST และ JSON-RPC เพื่อพัฒนา API สำหรับเว็บแอปพลิเคชัน พวกเขาเปรียบเทียบอย่างไร

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

ปัญหาพื้นฐานของ RPC คือการมีเพศสัมพันธ์ ไคลเอนต์ RPC มีการเชื่อมโยงกับการใช้งานบริการอย่างแน่นหนาและเป็นการยากที่จะเปลี่ยนการใช้งานบริการโดยไม่ทำให้ลูกค้าแตกหัก:

• ลูกค้าจะต้องรู้ชื่อขั้นตอน;
• ลำดับพารามิเตอร์ขั้นตอนประเภทและจำนวนเรื่อง ไม่ใช่เรื่องง่ายที่จะเปลี่ยนลายเซ็นขั้นตอน (จำนวนอาร์กิวเมนต์ลำดับของอาร์กิวเมนต์ประเภทอาร์กิวเมนต์ ฯลฯ ... ) ทางฝั่งเซิร์ฟเวอร์โดยไม่ทำให้การใช้งานของลูกค้าแตก
• สไตล์ RPC ไม่ได้เปิดเผยอะไรนอกจากโพรซีเดอร์ปลายทาง + อาร์กิวเมนต์โพรซีเดอร์ มันเป็นไปไม่ได้สำหรับลูกค้าที่จะกำหนดสิ่งที่สามารถทำได้ต่อไป

ในทางตรงกันข้ามในสไตล์ REST มันง่ายมากที่จะแนะนำลูกค้าโดยรวมถึงข้อมูลการควบคุมในการเป็นตัวแทน (ส่วนหัว HTTP + การเป็นตัวแทน) ตัวอย่างเช่น:

• เป็นไปได้ (และจำเป็นจริง ๆ ) ในการฝังลิงก์ที่มีคำอธิบายประกอบด้วยประเภทความสัมพันธ์ลิงก์ที่สื่อความหมายของ URIs เหล่านี้
• การใช้งานไคลเอนต์ไม่จำเป็นต้องขึ้นอยู่กับชื่อขั้นตอนและข้อโต้แย้งโดยเฉพาะ แต่ลูกค้าจะขึ้นอยู่กับรูปแบบข้อความ สิ่งนี้สร้างความเป็นไปได้ที่จะใช้ไลบรารีที่ปรับใช้แล้วสำหรับรูปแบบสื่อเฉพาะ (เช่น Atom, HTML, Collection + JSON, HAL ฯลฯ ... )
• เป็นไปได้ที่จะเปลี่ยน URIs ได้อย่างง่ายดายโดยไม่ทำให้ลูกค้าแตกเท่าที่พวกเขาต้องพึ่งพาการเชื่อมโยงที่ลงทะเบียน (หรือเฉพาะโดเมน) เท่านั้น
• เป็นไปได้ที่จะฝังโครงสร้างแบบฟอร์มคล้าย ๆ กันเพื่อให้ลูกค้ามีโอกาสที่จะเปิดเผยคำอธิบายเหล่านี้เป็นความสามารถของ UI หากผู้ใช้เป็นมนุษย์
• การสนับสนุนสำหรับการแคชเป็นข้อได้เปรียบเพิ่มเติม
• รหัสสถานะที่ได้มาตรฐาน

มีความแตกต่างและข้อได้เปรียบอีกมากมายที่ฝั่ง REST

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

หากคุณตัดสินใจใช้ RPC ความแตกต่างเพียงอย่างเดียวคือคุณกำลังระบุคำกริยาอย่างชัดเจนว่าเป็นส่วนหนึ่งของ URI ซึ่งมีความชัดเจนสอดคล้องสอดคล้องบั๊กน้อยและไม่มีปัญหาใด ๆ โดยเฉพาะอย่างยิ่งถ้าคุณสร้างแอปที่ก้าวข้าม CRUD ง่าย ๆ RPC เป็นวิธีเดียวที่จะไป ฉันมีปัญหาอีกประการหนึ่งกับนักปราชญ์ RESTful: HTTP POST, GET, PUT, DELETE มีความหมายที่ชัดเจนใน HTTP ซึ่งถูก REST โดย REST ให้หมายถึงสิ่งอื่น ๆ เพียงเพราะพวกเขาใช้เวลาส่วนใหญ่ - แต่ไม่ใช่ตลอดเวลา

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

ก่อนอื่น HTTP-REST เป็นสถาปัตยกรรม "การโอนย้ายสถานะแทน" สิ่งนี้แสดงถึงสิ่งที่น่าสนใจมากมาย:

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

ประการที่สอง HTTP-REST สอดคล้องกับ HTTP อย่างสมบูรณ์ (ดู "ปลอดภัย" และ "idempotent" ในส่วนก่อนหน้า) ดังนั้นคุณจะสามารถใช้ไลบรารี HTTP ซ้ำ (มีอยู่สำหรับทุกภาษาที่มีอยู่) และ HTTP reverse proxies ซึ่งจะทำให้คุณ ความสามารถในการใช้คุณสมบัติขั้นสูง (แคช, การตรวจสอบความถูกต้อง, การบีบอัด, การเปลี่ยนเส้นทาง, การเขียนใหม่, การบันทึก, ฯลฯ ) ด้วยรหัสบรรทัดศูนย์

สุดท้าย แต่ไม่ท้ายสุดการใช้ HTTP เป็นโปรโตคอล RPC เป็นข้อผิดพลาดอย่างมากตามผู้ออกแบบ HTTP 1.1 (และผู้ประดิษฐ์ REST): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation HTM # sec_6_5_2

คำตอบที่ยอดเยี่ยม - แค่ต้องการชี้แจงเกี่ยวกับความคิดเห็นบางส่วน JSON-RPC นั้นรวดเร็วและง่ายต่อการใช้งาน แต่เนื่องจากทรัพยากรและพารามิเตอร์ที่กล่าวมานั้นมีการเชื่อมโยงกันอย่างแน่นหนาและมีแนวโน้มที่จะพึ่งพาคำกริยา (api / deleteUser, api / addUser) โดยใช้ GET / POST โดยที่ REST จะให้ทรัพยากร ผู้ใช้) ว่าใน HTTP REST API อาศัยวิธีการ HTTP หลายวิธี (GET, POST, PUT, PATCH, DELETE) REST นั้นยากขึ้นเล็กน้อยสำหรับนักพัฒนามือใหม่ที่จะใช้งาน แต่รูปแบบได้กลายเป็นเรื่องธรรมดาไปแล้วและมันให้ความยืดหยุ่นมากขึ้นในระยะยาว (ทำให้ API ของคุณมีชีวิตที่ยืนยาวขึ้น)

นอกเหนือจากการไม่มีทรัพยากรที่เชื่อมโยงกันอย่างแน่นหนา REST ยังช่วยให้คุณหลีกเลี่ยงการมุ่งมั่นกับเนื้อหาประเภทเดียวซึ่งหมายความว่าหากลูกค้าของคุณต้องการรับข้อมูลในรูปแบบ XML หรือ JSON หรือแม้กระทั่ง YAML หากสร้างไว้ในระบบของคุณ ส่งคืนใด ๆ ที่ใช้ content-type / accept header

สิ่งนี้ช่วยให้คุณรักษา API ของคุณให้มีความยืดหยุ่นเพียงพอที่จะรองรับประเภทเนื้อหาใหม่หรือข้อกำหนดของลูกค้า

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

อย่างไรก็ตามด้วยสิ่งเหล่านี้ทั้งหมด - MOST APIs ไม่สงบ (อ้างอิงจาก Fielding) เนื่องจากไม่รวมไฮเปอร์มีเดีย (ลิงค์ไฮเปอร์เท็กซ์แบบฝังในการตอบสนองที่ช่วยนำทาง API) APIs ส่วนใหญ่คุณจะพบว่ามีลักษณะคล้ายกับ REST ซึ่งเป็นไปตามแนวคิดส่วนใหญ่ของ REST แต่ไม่ต้องสนใจข้อ จำกัด นี้ อย่างไรก็ตามมีการใช้งาน API เพิ่มมากขึ้นเรื่อย ๆ และกำลังกลายเป็นแนวปฏิบัติหลักของสตรีมมากขึ้น

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

โดยทั่วไปแล้วฉันจะบอกว่าส่วนที่เหลือเป็นวิธีที่จะไปหากคุณต้องการสร้าง API ที่ยืดหยุ่นและยืดออกได้ซึ่งจะมีอายุยืนยาว ด้วยเหตุนี้ฉันจึงบอกว่าเป็นเส้นทางที่จะไป 99% ของเวลา

ขอให้โชคดีไมค์

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

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

ถ้าไม่ใช่ (เช่นในกรณีที่สร้าง AJAX front-end ใน SPA) ตัวเลือกของฉันคือ RPC โดยเฉพาะอย่างยิ่ง JSON-RPC รวมกับ JSON Schema เป็นภาษาคำอธิบายและส่งผ่าน HTTP หรือ Websockets ขึ้นอยู่กับกรณีการใช้งาน

JSON-RPCเป็นสเปคที่เรียบง่ายและสง่างามที่กำหนดคำขอและการตอบสนอง JSON ส่วนของข้อมูลที่จะใช้ใน RPC แบบซิงโครนัสหรือแบบอะซิงโครนัส

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

ตัวเลือกของโปรโตคอลการขนส่ง (HTTP vs websockets) ขึ้นอยู่กับปัจจัยที่แตกต่างกันซึ่งเป็นสิ่งที่สำคัญที่สุดไม่ว่าคุณต้องการฟีเจอร์ HTTP (การแคช, การตรวจสอบความถูกต้องใหม่, ความปลอดภัย, idempotence, ประเภทเนื้อหา, หลายส่วน, ... ) หรือว่า ข้อความที่ frecuencies สูง

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

http://rpc.brutusin.org

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

http://demo.rpc.brutusin.org

หวังว่าจะช่วยเพื่อน!

Nacho

หากบริการของคุณใช้งานได้ดีกับรุ่นและรูปแบบ GET / POST / PUT / DELETE ให้ใช้ REST บริสุทธิ์

ฉันยอมรับว่า HTTP ได้รับการออกแบบมาสำหรับแอพพลิเคชั่นไร้สัญชาติ

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

• อัปเดตทันทีในทุกไคลเอนต์ (กำหนดการเรียก RPC เซิร์ฟเวอร์ต่อไคลเอ็นต์ของคุณเองสำหรับการอัพเดตโมเดล)
• เพิ่มความซับซ้อนได้ง่าย (ลองสร้าง Etherpad clone ด้วย REST เท่านั้น)
• หากคุณทำถูกต้อง (เพิ่ม RPC เป็นพิเศษสำหรับแบบเรียลไทม์) ส่วนใหญ่ยังคงใช้งานได้กับ REST เท่านั้น (ยกเว้นถ้าคุณสมบัติหลักคือการแชทหรืออะไรบางอย่าง)

เมื่อคุณออกแบบ API ฝั่งเซิร์ฟเวอร์เท่านั้นให้เริ่มต้นด้วยการกำหนดรุ่น REST และเพิ่มการสนับสนุน JSON-RPC ในภายหลังตามต้องการทำให้จำนวนการเรียก RPC เหลือน้อยที่สุด

(และขออภัยในวงเล็บมากเกินไป)

ฉันเป็นแฟนตัวยงของ REST ในอดีตและมีข้อได้เปรียบมากกว่า RPC บนกระดาษ คุณสามารถนำเสนอไคลเอนต์ที่มีประเภทเนื้อหาที่แตกต่างกัน, แคช, นำรหัสสถานะ HTTP มาใช้ซ้ำคุณสามารถแนะนำลูกค้าผ่าน API และคุณสามารถฝังเอกสารใน API หากส่วนใหญ่ไม่อธิบายด้วยตนเอง

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

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

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

ตามที่กำหนดรูปแบบชาร์ดสัน , คำถามไม่ได้ส่วนที่เหลือของ RPC เทียบกับแต่วิธี REST มาก ?

ในมุมมองนี้การปฏิบัติตามมาตรฐาน REST สามารถแบ่งได้เป็น 4 ระดับ

• ระดับ 0: คิดในแง่ของการกระทำและพารามิเตอร์ ตามที่อธิบายในบทความนี้เป็นหลักเทียบเท่ากับ JSON-RPC (บทความอธิบายมันสำหรับ XML-RPC แต่ข้อโต้แย้งที่เหมือนกันถือสำหรับทั้งสอง)
• ระดับ 1: คิดในแง่ของทรัพยากร ทุกสิ่งที่เกี่ยวข้องกับทรัพยากรเป็นของ URL เดียวกัน
• ระดับ 2: ใช้คำกริยา HTTP
• ระดับ 3: HATEOAS

ตามผู้สร้างมาตรฐาน REST บริการระดับ 3 เท่านั้นที่สามารถเรียกว่า RESTful อย่างไรก็ตามนี่เป็นตัวชี้วัดของการปฏิบัติตามไม่ใช่คุณภาพ หากคุณต้องการเรียกใช้ฟังก์ชันระยะไกลที่ใช้ในการคำนวณมันอาจไม่มีเหตุผลเลยที่จะมีลิงค์ไฮเปอร์มีเดียที่เกี่ยวข้องในการตอบสนองไม่แยกความแตกต่างของพฤติกรรมตาม HTTP กริยาที่ใช้ ดังนั้นการโทรดังกล่าวจึงมีแนวโน้มที่จะคล้าย RPC มากขึ้น อย่างไรก็ตามระดับการปฏิบัติตามที่ต่ำกว่านั้นไม่ได้หมายความว่าต้องมีสภาวะหรือมีเพศสัมพันธ์ที่สูงขึ้น อาจเป็นเพราะแทนที่จะคิดว่าREST กับ RPCคุณควรใช้ REST ให้มากที่สุดเท่าที่จะทำได้ แต่ไม่ควรมากกว่านี้ อย่าบิดแอปพลิเคชันของคุณเพียงเพื่อให้สอดคล้องกับมาตรฐานการปฏิบัติตาม RESTful

ทำไมต้อง JSON RPC:

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

อีกปัจจัยคือแม้ว่าเราจะมีตัวควบคุมที่แตกต่างกันสำหรับแต่ละวิธี / ฟังก์ชั่น แต่ไคลเอนต์ต้องจำไว้ว่าให้ใช้ POST หรือ GET สิ่งนี้ซับซ้อนยิ่งกว่านั้นอีก ด้านบนของที่จะส่งข้อมูลหนึ่งมีการตั้งค่าประเภทเนื้อหาของคำขอหากมีการใช้ POST

ในกรณีของ JSON RPC สิ่งต่าง ๆ จะง่ายขึ้นอย่างมากเพราะเซิร์ฟเวอร์ JSONRPC ส่วนใหญ่ทำงานในวิธีการ POST HTTP และประเภทเนื้อหาจะเป็น application / json เสมอ การทำเช่นนี้จะเป็นการโหลดของการจดจำเพื่อใช้วิธีการ HTTP และการตั้งค่าเนื้อหาที่เหมาะสมในฝั่งไคลเอ็นต์

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

ทำไมเหลือ:

คุณมี URL แยกต่างหากสำหรับการใช้งานที่แตกต่างกันซึ่งเซิร์ฟเวอร์ต้องการเปิดเผยต่อลูกค้า ดังนั้นคุณสามารถฝัง URL เหล่านี้ได้

ประเด็นเหล่านี้ส่วนใหญ่เป็นที่ถกเถียงกันและขึ้นอยู่กับความต้องการของบุคคล

ฉันคิดว่าเช่นเคยมันขึ้นอยู่กับ ...

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

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

ฉันเคยเริ่มต้นด้วย REST สำหรับแอปพลิเคชันหน้าเว็บเดียว แต่คำสั่งเม็ดเล็ก ๆ ระหว่างแอปพลิเคชันเว็บและเซิร์ฟเวอร์ทำให้ฉันบ้าอย่างรวดเร็ว ฉันควรเข้ารหัสเป็นพารามิเตอร์พา ธ หรือไม่ ในร่างกายหรือไม่ พารามิเตอร์การสืบค้น? ส่วนหัว? หลังจากการออกแบบ URL / กริยา / การตอบสนองฉันต้องรหัสระเบียบนี้ใน Javascript, ถอดรหัสใน Java แล้วเรียกวิธีการจริง แม้ว่าจะมีเครื่องมือมากมายสำหรับมันเป็นเรื่องยากมากที่จะไม่ได้รับความหมาย HTTP ใด ๆ ในรหัสโดเมนของคุณซึ่งเป็นการปฏิบัติที่ไม่ดีจริงๆ (การติดต่อกัน)

ลองสร้างไฟล์ Swagger / OpenAPI สำหรับไซต์ขนาดกลางที่ซับซ้อนและเปรียบเทียบกับอินเทอร์เฟซ Java เดียวที่อธิบายขั้นตอนระยะไกลในไฟล์นั้น การเพิ่มความซับซ้อนทำให้เซ

ฉันจึงเปลี่ยนจาก REST เป็น JSON-RPC สำหรับ webapp หน้าเดียว aI พัฒนาไลบรารีขนาดเล็กที่เข้ารหัสอินเตอร์เฟส Java บนเซิร์ฟเวอร์และส่งไปยังเบราว์เซอร์ ในเบราว์เซอร์สิ่งนี้สร้างพร็อกซีสำหรับรหัสแอปพลิเคชันที่ส่งคืนสัญญาสำหรับแต่ละฟังก์ชั่น

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

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

มันจะเป็นการดีกว่าที่จะเลือก JSON-RPC ระหว่าง REST และ JSON-RPC เพื่อพัฒนา API สำหรับเว็บแอปพลิเคชันที่เข้าใจได้ง่ายขึ้น JSON-RPC เป็นที่ต้องการเนื่องจากการแมปไปยังการเรียกเมธอดและการสื่อสารสามารถเข้าใจได้ง่าย

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

ความจริงที่แยก REST จาก JSON-RPC จริง ๆ แล้วก็คือมันจะตรวจสอบข้อ จำกัด ต่างๆอย่างรอบคอบเพื่อยืนยันความยืดหยุ่นทางสถาปัตยกรรม ข้อ จำกัด นั้นทำให้มั่นใจได้ว่าลูกค้าและเซิร์ฟเวอร์สามารถเติบโตได้อย่างอิสระจากกัน (การเปลี่ยนแปลงสามารถทำได้โดยไม่ยุ่งกับการใช้งานของลูกค้า) การโทรนั้นไร้สถานะ มีการเสนออินเทอร์เฟซสำหรับการโต้ตอบ API นั้นเป็นระบบขั้นสูง (Hall, 2010) JSON-RPC นั้นรวดเร็วและง่ายต่อการใช้งานอย่างไรก็ตามเป็นทรัพยากรที่กล่าวถึงและพารามิเตอร์มีการเชื่อมโยงกันอย่างแน่นหนาและมีแนวโน้มที่จะขึ้นอยู่กับคำกริยา (api / addUser, api / deleteUser) โดยใช้ GET / POST ในขณะที่ REST / users) ใน HTTP REST API ขึ้นอยู่กับวิธีการ HTTP หลายวิธีเช่น GET, PUT, POST, DELETE, PATCH

JSON (แสดงเป็น JavaScript Object Notation) เป็นรูปแบบ data-interchange ที่มีน้ำหนักเบาเป็นเรื่องง่ายสำหรับมนุษย์ที่จะอ่านและเขียน มันไม่ยุ่งยากสำหรับเครื่องจักรในการแยกและสร้าง JSON เป็นรูปแบบข้อความซึ่งเป็นภาษาที่เป็นอิสระทั้งหมด แต่มีระเบียบปฏิบัติที่คุ้นเคยกับโปรแกรมเมอร์ของตระกูลภาษาประกอบด้วย C #, C, C ++, Java, Perl, JavaScript, Python และอื่น ๆ อีกมากมาย คุณสมบัติดังกล่าวทำให้ JSON เป็นภาษาแลกเปลี่ยนข้อมูลที่สมบูรณ์แบบและเป็นทางเลือกที่ดีกว่าในการเลือกใช้

คำถามผิด: เรียกเก็บ manichean ที่ไม่มีอยู่จริง!

คุณสามารถใช้ JSON-RPC กับ "กริยาน้อย" (ไม่มีเมธอด ) และรักษามาตรฐานขั้นต่ำที่จำเป็นสำหรับ sendo id, พารามิเตอร์, รหัสข้อผิดพลาดและข้อความเตือน มาตรฐาน JSON-RPC ไม่พูดว่า "คุณไม่สามารถเป็น REST" ได้เพียงพูดวิธีบรรจุข้อมูลพื้นฐาน

มี "REST JSON-RPC" แล้ว ! REST คือ "วิธีปฏิบัติที่ดีที่สุด" สำหรับการบรรจุข้อมูลน้อยที่สุดด้วยสัญญาที่เรียบง่ายและมั่นคง

ตัวอย่าง

(จากคำตอบและบริบทการสอน)

เมื่อจัดการกับ REST โดยทั่วไปจะช่วยให้เริ่มต้นด้วยการคิดในแง่ของทรัพยากร ในกรณีนี้ทรัพยากรไม่ได้เป็นเพียง "บัญชีธนาคาร" แต่เป็นธุรกรรมของบัญชีธนาคารนั้น ... แต่ JSON-RPC ไม่ได้กำหนดพารามิเตอร์ "method" ทั้งหมดจะถูกเข้ารหัสโดย "เส้นทาง" ของจุดสิ้นสุด

• ส่วนที่เหลือในการฝากเงิน กับที่มีการร้องขอPOST /Bank/Account/John/Transaction JSON การตอบสนอง JSON อาจเป็นอะไรก็ได้{"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}
{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST ถอนออกด้วยPOST /Bank/Account/John/Transaction... ที่คล้ายกัน

• ... GET /Bank/Account/John/Transaction/12345@13... สิ่งนี้สามารถส่งคืนระเบียน JSON ของธุรกรรมที่แน่นอนนั้น (เช่นโดยทั่วไปผู้ใช้ของคุณต้องการบันทึกเดบิตและเครดิตในบัญชีของพวกเขา) {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}สิ่งที่เป็น แบบแผนเกี่ยวกับ (REST) ​​คำขอ GET สามารถรวมการเข้ารหัสรหัสโดย "@id" ดังนั้นไม่จำเป็นต้องส่ง JSON ใด ๆ แต่ยังคงใช้ JSON-RPC ในแพ็คการตอบสนอง

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

ฉันใช้ vdata สำหรับโปรโตคอล RPC: http://vdata.dekuan.org/

1, PHP และ JavaScript ต่างก็โอเค 2, การโทรข้ามทรัพยากรร่วมกัน (CORS) โทรยังคงโอเค