ฉันมีบริการเว็บที่ยอมรับพารามิเตอร์ JSON และมี URL เฉพาะสำหรับวิธีการเช่น:
http://IP:PORT/API/getAllData?p={JSON}
นี่ไม่ใช่ REST อย่างแน่นอนเนื่องจากไม่ใช่คนไร้สัญชาติ ต้องคำนึงถึงคุกกี้และมีเซสชันของตัวเอง
มันเป็น RPC หรือไม่? RPC และ REST ต่างกันอย่างไร
คำตอบ:
คุณไม่สามารถแยกชัดเจนระหว่าง REST หรือ RPC เพียงแค่ดูสิ่งที่คุณโพสต์
ข้อ จำกัด ประการหนึ่งของ REST คือต้องเป็นคนไร้สัญชาติ หากคุณมีเซสชันแสดงว่าคุณมีสถานะดังนั้นคุณจึงไม่สามารถเรียกใช้บริการของคุณ RESTful ได้
ความจริงที่ว่าคุณมีการดำเนินการใน URL ของคุณ (กล่าวคือgetAllData) เป็นข้อบ่งชี้ต่อ RPC ใน REST คุณแลกเปลี่ยนการเป็นตัวแทนและการดำเนินการที่คุณดำเนินการถูกกำหนดโดยคำกริยา HTTP นอกจากนี้ใน REST การเจรจาเนื้อหาจะไม่ดำเนินการกับ?p={JSON}พารามิเตอร์
ไม่รู้ว่าบริการของคุณเป็น RPC หรือไม่ แต่ไม่ใช่ RESTful คุณสามารถเรียนรู้เกี่ยวกับความแตกต่างออนไลน์ที่นี่เป็นบทความที่ให้คุณเริ่มต้น: Debunking ตำนานของ RPC และส่วนที่เหลือ คุณรู้ดีกว่าว่ามีอะไรอยู่ในบริการของคุณดังนั้นจึงควรเปรียบเทียบฟังก์ชันกับ RPC และสรุปข้อสรุป
พิจารณาตัวอย่าง HTTP API ต่อไปนี้ที่จำลองการสั่งซื้อในร้านอาหาร
วางคำสั่งซื้อ:
การเรียกคืนคำสั่งซื้อ:
การอัปเดตคำสั่งซื้อ:
ตัวอย่างจากsites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc
ดังที่คนอื่น ๆ กล่าวความแตกต่างที่สำคัญคือ REST เป็นคำนามเป็นศูนย์กลางและ RPC เป็นคำกริยาเป็นศูนย์กลาง ฉันแค่ต้องการรวมตารางตัวอย่างที่ชัดเจนซึ่งแสดงให้เห็นว่า:
--------------------------- + ---------------------- --------------- + -------------------------- การทำงาน | RPC (การดำเนินการ) | REST (ทรัพยากร) --------------------------- + ---------------------- --------------- + -------------------------- สมัคร | โพสต์ / สมัคร | POST / คน --------------------------- + ---------------------- --------------- + -------------------------- ลาออก | POST / ลาออก | ลบ / คน / 1234 --------------------------- + ---------------------- --------------- + -------------------------- คนอ่าน | รับ / readPerson? personid = 1234 | รับ / ท่าน / 1234 --------------------------- + ---------------------- --------------- + -------------------------- อ่านรายการของบุคคล | รับ / readUsersItemsList? userid = 1234 | รับ / ท่าน / 1234 / รายการ --------------------------- + ---------------------- --------------- + -------------------------- เพิ่มรายการในรายชื่อบุคคล | POST / addItemToUsersItemsList | POST / คน / 1234 / รายการ --------------------------- + ---------------------- --------------- + -------------------------- อัปเดตรายการ | โพสต์ / แก้ไขรายการ | PUT / items / 456 --------------------------- + ---------------------- --------------- + -------------------------- ลบรายการ | POST / removeItem? itemId = 456 | ลบ / items / 456 --------------------------- + ---------------------- --------------- + --------------------------
หมายเหตุ
GET /persons/1234) ในขณะที่ RPC มีแนวโน้มที่จะใช้พารามิเตอร์การสืบค้นสำหรับอินพุตฟังก์ชันGET /readPerson?personid=1234)GET /persons?height=tall)POST /signupหรือPOST /personsคุณรวมข้อมูลที่อธิบายบุคคลใหม่)มันเป็นRPC ใช้ http การใช้งาน REST ที่ถูกต้องควรแตกต่างจาก RPC เพื่อให้มีตรรกะในการประมวลผลข้อมูลเช่นเดียวกับวิธีการ / ฟังก์ชันคือ RPC getAllData () เป็นวิธีการที่ชาญฉลาด ส่วนที่เหลือไม่สามารถมีปัญญาก็ควรจะถ่ายโอนข้อมูลที่สามารถสอบถามโดยหน่วยสืบราชการลับภายนอก
การใช้งานส่วนใหญ่ที่ฉันเคยเห็นในปัจจุบันคือ RPC แต่หลายคนเรียกมันผิดว่า REST REST ด้วย HTTP เป็นผู้ช่วยชีวิตและ SOAP ที่มี XML คนร้าย ดังนั้นความสับสนของคุณเป็นสิ่งที่ถูกต้องและคุณพูดถูกไม่ใช่ REST
โปรโตคอล HTTP ไม่ทำให้การใช้งาน REST ทั้ง REST (GET, POST, PUT, PATCH, DELETE) และ RPC (GET + POST) สามารถพัฒนาผ่าน HTTP (เช่นผ่านโปรเจ็กต์ Web API ใน Visual Studio)
ดี แต่ REST คืออะไร? แบบจำลองวุฒิภาวะของริชาร์ดสันแสดงไว้ด้านล่าง (สรุป) เหลือเพียงระดับ 3 เท่านั้น
เช่นระดับ 3 (HATEOAS):
ลิงก์ระบุว่าอ็อบเจ็กต์นี้สามารถอัปเดตด้วยวิธีนี้และเพิ่มด้วยวิธีนี้
ลิงก์ระบุว่าวัตถุนี้สามารถอ่านได้เท่านั้นและนี่คือวิธีที่เราทำ
เห็นได้ชัดว่าการส่งข้อมูลไม่เพียงพอที่จะกลายเป็น REST แต่ควรกล่าวถึงวิธีการสืบค้นข้อมูลด้วย แต่แล้วอีกครั้งทำไม 4 ขั้นตอน? ทำไมถึงไม่เป็นแค่ขั้นตอนที่ 4 แล้วเรียกมันว่า REST ริชาร์ดสันให้แนวทางทีละขั้นตอนเพื่อไปที่นั่นนั่นคือทั้งหมด
คุณได้สร้างเว็บไซต์ที่มนุษย์สามารถใช้งานได้ แต่คุณสามารถสร้างเว็บไซต์ที่เครื่องจักรใช้งานได้ด้วยหรือไม่? นั่นคือที่มาของอนาคตและ RESTful Web Services จะแสดงวิธีการทำ
REST อธิบายได้ดีที่สุดในการทำงานกับทรัพยากรโดยที่ RPC เป็นข้อมูลเพิ่มเติมเกี่ยวกับการดำเนินการ
REST ย่อมาจาก Representational State Transfer เป็นวิธีง่ายๆในการจัดระเบียบปฏิสัมพันธ์ระหว่างระบบอิสระ แอพพลิเคชัน RESTful มักใช้คำขอ HTTP เพื่อโพสต์ข้อมูล (สร้างและ / หรืออัปเดต) อ่านข้อมูล (เช่นสร้างแบบสอบถาม) และลบข้อมูล ดังนั้น REST สามารถใช้ HTTP สำหรับการดำเนินการ CRUD ทั้งสี่ (สร้าง / อ่าน / อัปเดต / ลบ)
โดยทั่วไปแล้วRPCจะใช้ในการสื่อสารข้ามโมดูลต่างๆเพื่อตอบสนองคำขอของผู้ใช้ เช่นใน openstack เช่น nova, glance และ neutron ทำงานร่วมกันอย่างไรเมื่อบูตเครื่องเสมือน
ฉันจะเถียงด้วยเหตุนี้:
หน่วยงานของฉันถือ / เป็นเจ้าของข้อมูลหรือไม่ จากนั้น RPC: นี่คือสำเนาข้อมูลบางส่วนของฉันจัดการสำเนาข้อมูลที่ฉันส่งถึงคุณและส่งสำเนาผลลัพธ์ของคุณกลับมาให้ฉัน
หน่วยงานที่เรียกว่าถือ / เป็นเจ้าของข้อมูลหรือไม่ จากนั้น REST: อย่างใดอย่างหนึ่ง (1) แสดงสำเนาข้อมูลบางส่วนของคุณหรือ (2) จัดการข้อมูลบางส่วนของคุณ
ท้ายที่สุดแล้วก็คือ "ด้าน" ของการกระทำที่เป็นเจ้าของ / เก็บข้อมูล และใช่คุณสามารถใช้ REST verbiage เพื่อพูดคุยกับระบบที่ใช้ RPC ได้ แต่คุณจะยังคงทำกิจกรรม RPC เมื่อทำเช่นนั้น
ตัวอย่างที่ 1: ฉันมีวัตถุที่สื่อสารไปยังที่เก็บฐานข้อมูลเชิงสัมพันธ์ (หรือที่เก็บข้อมูลประเภทอื่น ๆ ) ผ่าน DAO เหมาะสมที่จะใช้สไตล์ REST สำหรับการโต้ตอบระหว่างอ็อบเจ็กต์ของฉันกับอ็อบเจ็กต์การเข้าถึงข้อมูลซึ่งสามารถมีอยู่ในรูปแบบ API เอนทิตีของฉันไม่ได้เป็นเจ้าของ / ถือข้อมูลฐานข้อมูลเชิงสัมพันธ์ (หรือที่เก็บข้อมูลที่ไม่ใช่เชิงสัมพันธ์) ทำ
ตัวอย่างที่ 2: ฉันต้องทำคณิตศาสตร์ที่ซับซ้อนจำนวนมาก ฉันไม่ต้องการโหลดวิธีการทางคณิตศาสตร์จำนวนมากลงในวัตถุของฉันฉันแค่ต้องการส่งผ่านค่าบางอย่างไปยังอย่างอื่นที่สามารถคำนวณทางคณิตศาสตร์ได้ทุกประเภทและได้ผลลัพธ์ สไตล์ RPC ก็สมเหตุสมผลแล้วเพราะวัตถุ / เอนทิตีทางคณิตศาสตร์จะเปิดเผยการดำเนินการทั้งหมดให้กับวัตถุของฉัน โปรดทราบว่าวิธีการเหล่านี้ทั้งหมดอาจถูกเปิดเผยเป็น API แต่ละรายการและฉันอาจเรียกวิธีใดก็ได้ด้วย GET ฉันสามารถอ้างได้ว่านี่คือ RESTful เพราะฉันโทรผ่าน HTTP GET แต่จริงๆแล้วภายใต้การครอบคลุมคือ RPC เอนทิตีของฉันเป็นเจ้าของ / เก็บข้อมูลเอนทิตีระยะไกลกำลังดำเนินการจัดการกับสำเนาของข้อมูลที่ฉันส่งไป
ผ่าน HTTP ทั้งคู่กลายเป็นแค่HttpRequestวัตถุและทั้งคู่คาดหวังว่าHttpResponseวัตถุจะกลับคืนมา ฉันคิดว่าใคร ๆ ก็สามารถเขียนโค้ดด้วยคำอธิบายนั้นต่อไปและกังวลเรื่องอื่น
มีคำตอบที่ดีมากมายที่นี่ ฉันจะยังคงแนะนำคุณไปที่บล็อกของ Google นี้เนื่องจากเป็นการพูดคุยเกี่ยวกับความแตกต่างระหว่าง RPC & REST และรวบรวมสิ่งที่ฉันไม่ได้อ่านในคำตอบใด ๆ ที่นี่
ฉันจะพูดย่อหน้าจากลิงค์เดียวกันกับที่โดดเด่นสำหรับฉัน:
REST เป็นคำอธิบายหลักการออกแบบที่รองรับ HTTP และเว็บทั่วโลก แต่เนื่องจาก HTTP เป็น REST API ที่มีความสำคัญทางการค้าเพียงอย่างเดียวเราจึงสามารถหลีกเลี่ยงการพูดคุยเกี่ยวกับ REST และมุ่งเน้นไปที่ HTTP ได้เป็นส่วนใหญ่ การทดแทนนี้มีประโยชน์เนื่องจากมีความสับสนและความแปรปรวนอย่างมากในสิ่งที่ผู้คนคิดว่า REST หมายถึงในบริบทของ API แต่มีความชัดเจนและเห็นพ้องกันมากขึ้นว่า HTTP คืออะไร แบบจำลอง HTTP เป็นตัวผกผันที่สมบูรณ์แบบของโมเดล RPC - ในโมเดล RPC หน่วยแอดเดรสคือโพรซีเดอร์และเอนทิตีของโดเมนปัญหาจะซ่อนอยู่หลังโพรซีเดอร์ ในโมเดล HTTP หน่วยแอดเดรสเป็นเอนทิตีเองและพฤติกรรมของระบบจะซ่อนอยู่หลังเอนทิตีเป็นผลข้างเคียงของการสร้างอัปเดตหรือลบออก
นี่คือวิธีที่ฉันเข้าใจและใช้ในกรณีการใช้งานที่แตกต่างกัน:
ตัวอย่าง: การจัดการร้านอาหาร
use-case สำหรับ REST : การจัดการคำสั่งซื้อ
- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123
สำหรับการจัดการทรัพยากร REST นั้นสะอาด จุดสิ้นสุดเดียวที่มีการดำเนินการที่กำหนดไว้ล่วงหน้า จะเห็นได้ว่าเป็นวิธีการแสดง DB (Sql หรือ NoSql) หรืออินสแตนซ์คลาสสู่โลก
ตัวอย่างการใช้งาน:
class order:
on_get(self, req, resp): doThis.
on_patch(self, req, resp): doThat.
ตัวอย่างกรอบ: Falcon สำหรับ python
กรณีใช้งานสำหรับ RPC : การจัดการการดำเนินการ
- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123
สำหรับงานวิเคราะห์ปฏิบัติงานไม่ตอบสนองไม่เป็นตัวแทนงานที่ใช้การกระทำ RPC จะทำงานได้ดีขึ้นและเป็นเรื่องธรรมดามากที่จะคิดว่าใช้งานได้จริง
ตัวอย่างการใช้งาน:
@route('/operation/cook/<orderId>')
def cook(orderId): doThis.
@route('/operation/serve/<orderId>')
def serve(orderId): doThat.
ตัวอย่างกรอบ: ขวดสำหรับ python