RPC กับ REST แตกต่างกันอย่างไร

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

อ่านเพิ่มเติมเกี่ยวกับ API »

อ่านเกี่ยวกับ RESTful APIs »

RPC และ REST มีความคล้ายคลึงกันอย่างไร

การเรียกใช้กระบวนการระยะไกล (RPC) และ REST ต่างเป็นวิธีการออกแบบ API API เป็นส่วนสำคัญในการออกแบบเว็บสมัยใหม่และระบบแบบการกระจายอื่นๆ โดยช่วยให้แยกแอปพลิเคชันหรือบริการแบบกระจายออกเป็น 2 ส่วนเพื่อสื่อสารโดยไม่ทราบวิธีการทำงานในระบบแต่ละฝั่ง ทั้ง 2 แอปพลิเคชันหรือบริการอาจจะไม่ต้องเกี่ยวข้องกันมากนัก ยกเว้นในกรณีการแลกเปลี่ยนข้อมูลขนาดเล็ก 

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

ในลำดับต่อไป เราจะพูดถึงความคล้ายคลึงกันด้านอื่นๆ ระหว่าง RPC กับ REST API

การกำหนดสาระสำคัญ

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

การสื่อสาร

ทั้ง REST และ RPC ใช้ HTTP เป็นโปรโตคอลพื้นฐาน รูปแบบข้อความที่นิยมมากที่สุดใน RPC และ REST คือ JSON และ XML JSON เป็นที่นิยมเนื่องจากความสามารถในการอ่านและความยืดหยุ่น

ความเข้ากันได้ข้ามภาษา

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

หลักการสถาปัตยกรรมระหว่าง RPC กับ REST

ในการเรียกใช้กระบวนการระยะไกล (RPC) ไคลเอ็นต์จะเรียกใช้ฟังก์ชันระยะไกล (เรียกอีกอย่างว่า วิธีการหรือขั้นตอน) บนเซิร์ฟเวอร์ โดยปกติแล้ว ค่าข้อมูลอย่างน้อย 1 ค่าจะส่งไปยังเซิร์ฟเวอร์ในระหว่างการเรียกใช้

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

RPC มุ่งเน้นไปที่ฟังก์ชันหรือการดำเนินการ ในขณะที่ REST มุ่งเน้นไปที่ทรัพยากรหรืออ็อบเจกต์

หลักการของ RPC

ต่อไปเราจะพูดถึงหลักการบางส่วนที่ระบบ RPC มักจะดำเนินการตาม อย่างไรก็ตาม หลักการเหล่านี้ไม่ได้เป็นมาตรฐานเหมือนกับ REST

การเรียกดำเนินการระยะไกล

ไคลเอ็นต์ไจะเรียกใช้ RPC ไปยังฟังก์ชันบนเซิร์ฟเวอร์ระยะไกลราวกับมีการเรียกใช้ในเครื่องไปยังไคลเอ็นต์

พารามิเตอร์ที่ส่ง

ไคลเอ็นต์มักจะส่งพารามิเตอร์ไปยังฟังก์ชันเซิร์ฟเวอร์ ซึ่งคล้ายคลึงกันมากกับฟังก์ชันในเครื่อง

โค้ดจำลอง

โค้ดจำลองฟังก์ชันที่มีอยู่ในทั้งไคลเอ็นต์และเซิร์ฟเวอร์ โค้ดจะทำการเรียกใช้ฟังก์ชันในฝั่งไคลเอ็นต์ โค้ดจะเรียกดำเนินการฟังก์ชันจริงบนเซิร์ฟเวอร์

หลักการของ REST

หลักการของ REST เป็นมาตรฐานเดียวกัน REST API ต้องดำเนินการตามหลักการเหล่านี้เพื่อให้ได้รับการจัดประเภทเป็น RESTful

ไคลเอ็นต์กับเซิร์ฟเวอร์

สถาปัตยกรรมระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ของ REST จะแยกไคลเอ็นต์และเซิร์ฟเวอร์ โดยถือว่าเป็นระบบแยกอิสระจากกัน

ไม่บันทึกสถานะ

เซิร์ฟเวอร์ไม่เก็บบันทึกสถานะของไคลเอ็นต์ระหว่างคำขอต่างๆ ของไคลเอ็นต์

สามารถแคชได้ 

ไคลเอ็นต์หรือระบบตัวกลางอาจแคชตอบสนองของเซิร์ฟเวอร์ โดยขึ้นอยู่กับว่าไคลเอ็นต์ระบุว่าการตอบสนองอาจถูกแคชไว้หรือไม่

ระบบที่แบ่งออกเป็นชั้น

ตัวกลางสามารถอยู่ระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ได้ ทั้งไคลเอ็นต์และเซิร์ฟเวอร์จะไม่ทราบว่ามีตัวกลาง และทำงานเหมือนได้เชื่อมต่อกันโดยตรง

อินเทอร์เฟซรูปแบบเดียวกัน

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

วิธีการทำงาน: RPC กับ REST

ในการเรียกกระบวนการระยะไกล (RPC) ไคลเอ็นต์ใช้ HTTP POST เพื่อเรียกใช้ฟังก์ชันเฉพาะตามชื่อ นักพัฒนาฝั่งไคลเอ็นต์ต้องทราบชื่อฟังก์ชันและพารามิเตอร์ล่วงหน้าเพื่อให้ RPC ทำงานได้

ใน REST ไคลเอ็นต์และเซิร์ฟเวอร์ใช้คำกริยา HTTP เช่น GET, POST, PATCH, PUT, DELETE และ OPTIONS เพื่อดำเนินการกับตัวเลือก นักพัฒนาจะต้องทราบเพียง URL ของทรัพยากรเซิร์ฟเวอร์ และไม่จำเป็นต้องกังวลกับชื่อฟังก์ชันแต่ละรายการ

ตารางต่อไปนี้แสดงประเภทของโค้ดที่ไคลเอ็นต์ใช้ในการดำเนินการที่คล้ายกันใน RPC และ REST

การดำเนินการ

RPC

REST

ความคิดเห็น

การเพิ่มผลิตภัณฑ์ใหม่ลงในรายการผลิตภัณฑ์

POST /addProduct HTTP/1.1

HOST: api.example.com

Content-Type: application/json

{"name": "T-Shirt", "price": "22.00", "category": "Clothes"}

POST /products HTTP/1.1

HOST: api.example.com

Content-Type: application/json

{"name": "T-Shirt", "price": "22.00", "category": "Clothes"}

RPC ใช้ POST บนฟังก์ชัน และ REST ใช้ POST บน URL

การเรียกดูรายละเอียดของผลิตภัณฑ์

POST /getProduct HTTP/1.1

HOST: api.example.com

Content-Type: application/json

{"productID": "123”}

GET /products/123 HTTP/1.1

HOST: api.example.com

RPC ใช้ POST บนฟังก์ชันและส่งพารามิเตอร์เป็นอ็อบเจกต์ JSON REST ใช้ GET บน URL และส่งพารามิเตอร์ใน URL

การอัปเดตราคาของผลิตภัณฑ์

POST /updateProductPrice HTTP/1.1

HOST: api.example.com

Content-Type: application/json

{"productId": "123", "newPrice": "20.00"}

PUT /products/123 HTTP/1.1

HOST: api.example.com

Content-Type: application/json

{"price": "20.00"}

RPC ใช้ POST บนฟังก์ชันและส่งพารามิเตอร์เป็นอ็อบเจกต์ JSON REST ใช้ PUT บน URL และส่งพารามิเตอร์ใน URL และเป็นอ็อบเจกต์ JSON

การลบผลิตภัณฑ์

POST /deleteProduct HTTP/1.1

HOST: api.example.com

Content-Type: application/json

{"productId": "123""}

DELETE /products/123 HTTP/1.1

HOST: api.example.com

RPC ใช้ POST บนฟังก์ชันและส่งพารามิเตอร์เป็นอ็อบเจกต์ JSON REST ใช้ DELETE บน URL และส่งพารามิเตอร์ใน URL

ความแตกต่างที่สำคัญเมื่อเทียบกับ REST

การเรียกใช้กระบวนการระยะไกล (RPC) และ REST ต่างเป็นวิธีการออกแบบอินเทอร์เฟซระบบไคลเอ็นต์และเซิร์ฟเวอร์ที่สอดคล้องกันสำหรับการสื่อสารผ่านทางอินเทอร์เน็ต อย่างไรก็ตาม โครงสร้าง การนำไปใช้ และหลักการพื้นฐานจะแตกต่างกัน ระบบที่ออกแบบด้วย REST มีชื่อเรียกว่า RESTful API ในขณะที่ระบบที่ออกแบบด้วย RPC จะเรียกว่า RPC API

ในลำดับต่อไป เราจะแสดงให้เห็นถึงความแตกต่างกันมากขึ้น

เวลาในการพัฒนา

RPC ได้รับการพัฒนาขึ้นในช่วงปลายคริสต์ทศวรรษ 1970 และต้นคริสต์ทศวรรษ 1980 ในขณะที่ REST เป็นคำที่คิดค้นขึ้นครั้งแรกโดยนักวิทยาศาสตร์คอมพิวเตอร์ Roy Fielding ในปี 2000

รูปแบบการดำเนินการ

REST API มีชุดการดำเนินการมาตรฐานบนเซิร์ฟเวอร์เนื่องจากใช้วิธีการ HTTP แต่ RPC API ไม่มี ในการ RPC ไปใช้งานบางกรณีจะมีกรอบการทำงานสำหรับการดำเนินการมาตรฐาน

รูปแบบการส่งข้อมูล

REST สามารถส่งรูปแบบข้อมูลใดๆ และหลายรูปแบบได้ เช่น JSON และ XML ภายใน API เดียวกัน

อย่างไรก็ตาม เมื่อใช้ RPC API รูปแบบข้อมูลจะถูกเลือกโดยเซิร์ฟเวอร์และแก้ไขในระหว่างการนำไปใช้ คุณมีการใช้งาน JSON RPC หรือ XML RPC ได้บางรายการ และไคลเอ็นต์ไม่มีความยืดหยุ่น

รัฐ

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

ระบบ REST จะต้องไม่บันทึกสถานะอยู่เสมอ แต่ระบบ RPC อาจบันทึกหรือไม่บันทึกสถานะก็ได้ โดยขึ้นอยู่กับการออกแบบ

เมื่อใดที่ควรใช้ RPC หรือ REST

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

การดำเนินการต่อไปนี้เหมาะที่จะใช้ RPC

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

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

การดำเนินการต่อไปนี้เหมาะที่จะใช้ REST API

  • เพิ่มผลิตภัณฑ์ลงในฐานข้อมูล
  • เรียกดูเนื้อหาของเพลย์ลิสต์เพลง
  • อัปเดตที่อยู่ของบุคคล
  • ลบบล็อกโพสต์

ทำไม REST จึงมาแทนที่ RPC

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

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

สรุปความแตกต่างระหว่าง RPC กับ REST

 

RPC

REST

คืออะไร

ระบบช่วยให้ไคลเอ็นต์ระยะไกลสามารถเรียกใช้ขั้นตอนบนเซิร์ฟเวอร์เหมือนกับการเรียกใช้ในเครื่องได้ 

ชุดของกฎที่กำหนดการแลกเปลี่ยนข้อมูลที่มีโครงสร้างระหว่างไคลเอ็นต์และเซิร์ฟเวอร์

ใช้สำหรับ

การดำเนินการบนเซิร์ฟเวอร์ระยะไกล

สร้าง อ่าน อัปเดต และลบ (CRUD) การดำเนินการบนอ็อบเจกต์ระยะไกล

เหมาะสมที่สุด

เมื่อต้องใช้การคำนวณที่ซับซ้อนหรือเริ่มต้นกระบวนการระยะไกลบนเซิร์ฟเวอร์

เมื่อข้อมูลเซิร์ฟเวอร์และโครงสร้างข้อมูลจ้องมีการเปิดเผยอย่างสม่ำเสมอ

การบันทึกสถานะ

ไม่บันทึกสถานะหรือบันทึกสถานะ

ไม่บันทึกสถานะ

รูปแบบการส่งข้อมูล

ในโครงสร้างที่สอดคล้องกันซึ่งกำหนดโดยเซิร์ฟเวอร์และบังคับใช้บนไคลเอ็นต์

ในโครงสร้างที่กำหนดโดยอิสระจากเซิร์ฟเวอร์ รูปแบบที่แตกต่างกันหลายรายการสามารถส่งภายใน API เดียวกันได้

AWS สนับสนุนความต้องการ API ของคุณได้อย่างไร

Amazon Web Services (AWS) มีบริการและเครื่องมือมากมายที่จะช่วยนักออกแบบ API ในการสร้าง เรียกใช้ รวมถึงจัดการแอปพลิเคชันและบริการที่ใช้ API ที่ทันสมัย สำหรับข้อมูลเพิ่มเติม โปรดอ่านเกี่ยวกับการสร้างแอปพลิเคชันที่ทันสมัยบน AWS

ต่อไปนี้คือตัวอย่างบริการ AWS ที่ช่วยให้เป็นไปตามข้อกำหนด API ของคุณได้

  • เกตเวย์ของ Amazon API ช่วยให้นักพัฒนาสามารถสร้าง เผยแพร่ และจัดการ API ในวงกว้างได้ เกตเวย์ของ API ช่วยให้คุณสามารถสร้าง REST API ที่เหมาะสำหรับสถาปัตยกรรมไมโครเซอร์วิสที่มีคอนเทนเนอร์และแอปพลิเคชันบนเว็บ
  • Elastic Load Balancing (ELB) กระจายการรับส่งข้อมูลเครือข่ายเพื่อปรับปรุงความสามารถในการปรับขนาดแอปพลิเคชัน โดยสามารถกำหนดเส้นทางและปรับสมดุลโหลดการรับส่งข้อมูล gRPC ระหว่างไมโครเซอร์วิส หรือระหว่างไคลเอ็นต์และบริการที่เปิดใช้งาน gRPC การทำงานนี้ช่วยให้สามารถใช้ระบบจัดการการรับส่งข้อมูลของ gRPC ในสถาปัตยกรรมซอฟต์แวร์ได้อย่างราบรื่น โดยไม่ต้องเปลี่ยนแปลงโครงสร้างพื้นฐานใดๆ สำหรับไคลเอ็นต์หรือบริการของลูกค้า
  • Amazon Virtual Private Cloud (Amazon VPC) Lattice เป็นบริการเครือข่ายแอปพลิเคชันที่เชื่อมต่อ ตรวจสอบ และรักษาความปลอดภัยของการสื่อสารระหว่างบริการของคุณอย่างต่อเนื่อง ปรับขนาดทรัพยากรการประมวลผลและเครือข่ายโดยอัตโนมัติเพื่อรองรับเวิร์กโหลด HTTP, HTTPS และ gRPC ที่มีแบนวิดท์สูง

เริ่มต้นใช้งาน REST API และ Remote Procedure Call (RPC) API บน AWS ด้วยการสร้างบัญชีวันนี้