Tôi có một dịch vụ web chấp nhận các tham số JSON và có các URL cụ thể cho các phương thức, ví dụ:
http://IP:PORT/API/getAllData?p={JSON}
Đây chắc chắn không phải là REST vì nó không phải là không trạng thái. Nó có tính đến cookie và có phiên riêng của nó.
Nó có phải là RPC không? Sự khác biệt giữa RPC và REST là gì?
Câu trả lời:
Bạn không thể phân biệt rõ ràng giữa REST hoặc RPC chỉ bằng cách nhìn vào những gì bạn đã đăng.
Một hạn chế của REST là nó phải không trạng thái. Nếu bạn có một phiên thì bạn có trạng thái nên bạn không thể gọi dịch vụ của mình là RESTful.
Thực tế là bạn có một hành động trong URL của mình (tức là getAllData) là một dấu hiệu đối với RPC. Trong REST, bạn trao đổi các đại diện và hoạt động bạn thực hiện được quyết định bởi các động từ HTTP. Ngoài ra, trong REST, thương lượng nội dung không được thực hiện với một ?p={JSON}tham số.
Không biết dịch vụ của bạn có phải là RPC hay không, nhưng nó không phải là RESTful. Bạn có thể tìm hiểu về sự khác biệt trực tuyến, đây là một bài viết để giúp bạn bắt đầu: Gỡ bỏ những lầm tưởng của RPC & REST . Bạn biết rõ hơn những gì bên trong dịch vụ của bạn, vì vậy hãy so sánh các chức năng của nó với RPC là gì và đưa ra kết luận của riêng bạn.
Hãy xem xét ví dụ sau về các API HTTP mô hình hóa các đơn hàng được đặt trong một nhà hàng.
Đặt hàng:
Lấy đơn hàng:
Cập nhật Đơn hàng:
Ví dụ được lấy từ sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc
Như những người khác đã nói, một sự khác biệt chính là REST là trung tâm danh từ và RPC là trung tâm động từ. Tôi chỉ muốn đưa vào bảng các ví dụ rõ ràng này chứng minh rằng:
--------------------------- + ---------------------- --------------- + -------------------------- Hoạt động | RPC (hoạt động) | REST (tài nguyên) --------------------------- + ---------------------- --------------- + -------------------------- Đăng ký | ĐĂNG / đăng ký | POST / người --------------------------- + ---------------------- --------------- + -------------------------- Từ chức | ĐĂNG / từ chức | XÓA / người / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Đọc người | GET / readPerson? Personid = 1234 | NHẬN / người / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Đọc danh sách mục của người | GET / readUsersItemsList? Userid = 1234 | GET / người / 1234 / mặt hàng --------------------------- + ---------------------- --------------- + -------------------------- Thêm mục vào danh sách của người | POST / addItemToUsersItemsList | POST / người / 1234 / mặt hàng --------------------------- + ---------------------- --------------- + -------------------------- Cập nhật mặt hàng | ĐĂNG / sửa đổi mục | PUT / mục / 456 --------------------------- + ---------------------- --------------- + -------------------------- Xóa mục | POST / removeItem? ItemId = 456 | DELETE / mục / 456 --------------------------- + ---------------------- --------------- + --------------------------
Ghi chú
GET /persons/1234), trong khi RPC có xu hướng sử dụng các tham số truy vấn cho đầu vào hàm GET /readPerson?personid=1234).GET /persons?height=tall:).POST /signuphoặc POST /persons, bạn bao gồm dữ liệu mô tả người mới).Đó là RPC sử dụng http . Việc triển khai đúng REST phải khác với RPC. Để có một logic để xử lý dữ liệu, như một phương thức / hàm, là RPC. getAllData () là một phương thức thông minh. REST không thể có trí thông minh, nó phải là dữ liệu kết xuất có thể được truy vấn bởi trí thông minh bên ngoài .
Hầu hết các triển khai tôi đã thấy những ngày này là RPC nhưng nhiều người nhầm lẫn gọi nó là REST. REST với HTTP là vị cứu tinh và SOAP với XML là kẻ xấu. Vì vậy, sự nhầm lẫn của bạn là chính đáng và bạn đúng, nó không phải là REST.
Giao thức Http không thực hiện REST. Cả REST (GET, POST, PUT, PATCH, DELETE) và RPC (GET + POST) đều có thể được phát triển thông qua HTTP (ví dụ: thông qua một dự án API web trong studio trực quan).
Tốt thôi, nhưng REST là gì? Mô hình trưởng thành của Richardson được đưa ra dưới đây (tóm tắt). Chỉ có cấp độ 3 là RESTful.
ví dụ: cấp 3 (HATEOAS):
Liên kết trạng thái đối tượng này có thể được cập nhật theo cách này và được thêm vào theo cách này.
Liên kết cho biết đối tượng này chỉ có thể được đọc và đây là cách chúng tôi thực hiện.
Rõ ràng, việc gửi dữ liệu không đủ để trở thành REST, nhưng cách truy vấn dữ liệu, cũng cần được đề cập. Nhưng sau đó một lần nữa, tại sao lại là 4 bước? Tại sao không thể chỉ là Bước 4 và gọi nó là REST? Richardson chỉ cho chúng tôi cách tiếp cận từng bước để đạt được điều đó, chỉ có vậy.
Bạn đã xây dựng các trang web mà con người có thể sử dụng. Nhưng bạn cũng có thể xây dựng các trang web có thể sử dụng được bằng máy móc? Đó là nơi đặt tương lai và RESTful Web Services chỉ cho bạn cách thực hiện điều đó.
Tái bút: REST siêu phổ biến, kiểm thử tự động cũng vậy nhưng khi nói đến các ví dụ trong thế giới thực thì .. tốt ..
REST được mô tả tốt nhất để làm việc với các tài nguyên, trong đó RPC thiên về các hành động.
REST là viết tắt của Chuyển trạng thái đại diện. Đó là một cách đơn giản để tổ chức các tương tác giữa các hệ thống độc lập. Các ứng dụng RESTful thường sử dụng các yêu cầu HTTP để đăng dữ liệu (tạo và / hoặc cập nhật), đọc dữ liệu (ví dụ: thực hiện truy vấn) và xóa dữ liệu. Do đó, REST có thể sử dụng HTTP cho cả bốn hoạt động CRUD (Tạo / Đọc / Cập nhật / Xóa).
RPC về cơ bản được sử dụng để giao tiếp giữa các mô-đun khác nhau để phục vụ các yêu cầu của người dùng. ví dụ: Trong openstack như cách nova, liếc và neutron hoạt động cùng nhau khi khởi động máy ảo.
Tôi sẽ lập luận như vậy:
Tổ chức của tôi có nắm giữ / sở hữu dữ liệu không? Sau đó, RPC: đây là bản sao một số dữ liệu của tôi, thao tác với bản sao dữ liệu tôi gửi cho bạn và trả lại cho tôi bản sao kết quả của bạn.
Thực thể được gọi có nắm giữ / sở hữu dữ liệu không? Sau đó REST: hoặc (1) cho tôi xem bản sao một số dữ liệu của bạn hoặc (2) thao tác với một số dữ liệu của bạn.
Cuối cùng, nó là về "bên" của hành động sở hữu / lưu giữ dữ liệu. Và có, bạn có thể sử dụng REST verbiage để nói chuyện với hệ thống dựa trên RPC, nhưng bạn vẫn sẽ thực hiện hoạt động RPC khi làm như vậy.
Ví dụ 1: Tôi có một đối tượng đang giao tiếp với kho lưu trữ cơ sở dữ liệu quan hệ (hoặc bất kỳ kiểu lưu trữ dữ liệu nào khác) qua DAO. Có lý khi sử dụng kiểu REST cho tương tác giữa đối tượng của tôi và đối tượng truy cập dữ liệu có thể tồn tại dưới dạng API. Thực thể của tôi không sở hữu / giữ dữ liệu, cơ sở dữ liệu quan hệ (hoặc kho dữ liệu không quan hệ) thì có.
Ví dụ 2: Tôi cần làm rất nhiều phép toán phức tạp. Tôi không muốn tải một loạt các phương thức toán học vào đối tượng của mình, tôi chỉ muốn chuyển một số giá trị cho một thứ khác có thể thực hiện tất cả các loại toán học và nhận được kết quả. Sau đó, kiểu RPC có ý nghĩa, vì đối tượng / thực thể toán học sẽ hiển thị cho đối tượng của tôi một loạt các phép toán. Lưu ý rằng tất cả các phương pháp này có thể được hiển thị dưới dạng các API riêng lẻ và tôi có thể gọi bất kỳ phương thức nào trong số chúng bằng GET. Tôi thậm chí có thể khẳng định đây là RESTful vì tôi đang gọi thông qua HTTP GET nhưng thực sự thì nó là RPC. Thực thể của tôi sở hữu / nắm giữ dữ liệu, thực thể ở xa chỉ thực hiện các thao tác trên các bản sao của dữ liệu mà tôi đã gửi đến nó.
Có rất nhiều câu trả lời hay ở đây. Tôi vẫn sẽ giới thiệu bạn đến blog google này vì nó thực sự rất tốt trong việc thảo luận về sự khác biệt giữa RPC & REST và nắm bắt điều gì đó mà tôi chưa đọc trong bất kỳ câu trả lời nào ở đây.
Tôi sẽ trích dẫn một đoạn văn từ cùng một liên kết nổi bật với tôi:
Bản thân REST là một mô tả về các nguyên tắc thiết kế làm nền tảng cho HTTP và web trên toàn thế giới. Nhưng vì HTTP là API REST duy nhất quan trọng về mặt thương mại, chúng ta hầu như có thể tránh thảo luận về REST và chỉ tập trung vào HTTP. Sự thay thế này rất hữu ích vì có rất nhiều sự nhầm lẫn và thay đổi trong những gì mọi người nghĩ REST có nghĩa là trong ngữ cảnh của các API, nhưng có nhiều sự rõ ràng và thống nhất về chính HTTP là gì. Mô hình HTTP là nghịch đảo hoàn hảo của mô hình RPC — trong mô hình RPC, các đơn vị có thể định địa chỉ là các thủ tục và các thực thể của miền vấn đề được ẩn sau các thủ tục. Trong mô hình HTTP, các đơn vị có thể định địa chỉ là bản thân các thực thể và các hành vi của hệ thống được ẩn sau các thực thể như là tác dụng phụ của việc tạo, cập nhật hoặc xóa chúng.
Đây là cách tôi hiểu và sử dụng chúng trong các trường hợp sử dụng khác nhau:
Ví dụ: Quản lý nhà hàng
use-case cho REST : quản lý đơn hàng
- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123
Đối với quản lý tài nguyên, REST là sạch. Một điểm cuối với các hành động được xác định trước. Nó có thể được coi là một cách để hiển thị DB (Sql hoặc NoSql) hoặc các cá thể lớp với thế giới.
Ví dụ triển khai:
class order:
on_get(self, req, resp): doThis.
on_patch(self, req, resp): doThat.
Ví dụ về khung: Falcon cho python.
use-case cho RPC : quản lý hoạt động
- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123
Đối với các công việc phân tích, hoạt động, không phản hồi, không đại diện, dựa trên hành động, RPC hoạt động tốt hơn và việc suy nghĩ theo chức năng là điều rất tự nhiên.
Ví dụ triển khai:
@route('/operation/cook/<orderId>')
def cook(orderId): doThis.
@route('/operation/serve/<orderId>')
def serve(orderId): doThat.
Ví dụ khung: Flask cho python