REST vs JSON-RPC? [đóng cửa]

Tôi đang cố gắng chọn giữa REST và JSON-RPC để phát triển API cho ứng dụng web. Làm thế nào để họ so sánh?

Cập nhật 2015: Tôi đã thấy REST dễ dàng phát triển và sử dụng hơn cho API được phục vụ trên Web / HTTP, bởi vì giao thức HTTP hiện có và hoàn thiện được cả máy khách và máy chủ hiểu được có thể được API sử dụng. Ví dụ: mã phản hồi, tiêu đề, truy vấn, nội dung bài đăng, bộ đệm và nhiều tính năng khác có thể được API sử dụng mà không cần bất kỳ nỗ lực hoặc thiết lập bổ sung nào.

Vấn đề cơ bản với RPC là khớp nối. Các máy khách RPC trở nên gắn kết chặt chẽ với việc triển khai dịch vụ theo nhiều cách và rất khó để thay đổi triển khai dịch vụ mà không phá vỡ các máy khách:

• Khách hàng được yêu cầu phải biết tên thủ tục;
• Thủ tục tham số thứ tự, loại và tính vấn đề. Không dễ để thay đổi chữ ký thủ tục (số lượng đối số, thứ tự của đối số, loại đối số, v.v.) ở phía máy chủ mà không phá vỡ triển khai của máy khách;
• Kiểu RPC không để lộ bất cứ thứ gì ngoại trừ điểm cuối thủ tục + đối số thủ tục. Khách hàng không thể xác định những gì có thể được thực hiện tiếp theo.

Mặt khác, theo kiểu REST, rất dễ dàng hướng dẫn khách hàng bằng cách đưa thông tin điều khiển vào các biểu diễn (tiêu đề HTTP + biểu diễn). Ví dụ:

• Có thể (và thực sự bắt buộc) để nhúng các liên kết được chú thích bằng các loại quan hệ liên kết truyền đạt ý nghĩa của các URI này;
• Việc triển khai máy khách không cần phụ thuộc vào tên và đối số thủ tục cụ thể. Thay vào đó, khách hàng phụ thuộc vào định dạng tin nhắn. Điều này tạo ra khả năng sử dụng các thư viện đã được triển khai cho các định dạng phương tiện cụ thể (ví dụ: Atom, HTML, Collection + JSON, HAL, v.v.)
• Có thể dễ dàng thay đổi URI mà không phá vỡ ứng dụng khách khi chúng chỉ phụ thuộc vào quan hệ liên kết đã đăng ký (hoặc tên miền cụ thể);
• Có thể nhúng các cấu trúc giống như biểu mẫu trong các biểu diễn, cung cấp cho khách hàng khả năng hiển thị các mô tả này dưới dạng khả năng UI nếu người dùng cuối là con người;
• Hỗ trợ cho bộ nhớ đệm là lợi thế bổ sung;
• Mã trạng thái chuẩn hóa;

Có nhiều sự khác biệt và lợi thế hơn về phía REST.

Tôi đã tìm hiểu vấn đề một cách chi tiết và quyết định rằng REST thuần túy quá hạn chế và RPC là tốt nhất, mặc dù hầu hết các ứng dụng của tôi là ứng dụng CRUD. Nếu bạn dính vào REST, cuối cùng bạn sẽ phải gãi đầu tự hỏi làm thế nào bạn có thể dễ dàng thêm một phương thức cần thiết khác vào API cho một số mục đích đặc biệt. Trong nhiều trường hợp, cách duy nhất để làm điều đó với REST là tạo một bộ điều khiển khác cho nó, điều này có thể làm phức tạp quá mức chương trình của bạn.

Nếu bạn quyết định về RPC, sự khác biệt duy nhất là bạn rõ ràng chỉ định động từ là một phần của URI, rõ ràng, nhất quán, ít lỗi và thực sự không gặp rắc rối. Đặc biệt nếu bạn tạo một ứng dụng vượt xa CRUD đơn giản, RPC là cách duy nhất để đi. Tôi có một vấn đề khác với những người theo chủ nghĩa thuần túy RESTful: HTTP POST, GET, PUT, DELETE có ý nghĩa nhất định trong HTTP đã bị REST lật đổ thành những thứ khác, đơn giản là vì chúng phù hợp với hầu hết thời gian - nhưng không phải lúc nào cũng vậy.

Trong lập trình, từ lâu tôi đã phát hiện ra rằng cố gắng sử dụng một điều có nghĩa là hai điều sẽ xảy ra đôi khi và cắn bạn. Tôi muốn có khả năng sử dụng POST cho mọi hành động, bởi vì nó cung cấp sự tự do để gửi và nhận dữ liệu như phương pháp của bạn cần làm. Bạn không thể phù hợp với cả thế giới vào CRUD.

Đầu tiên, HTTP-REST là một kiến ​​trúc "chuyển trạng thái đại diện". Điều này ngụ ý rất nhiều điều thú vị:

• API của bạn sẽ không trạng thái và do đó dễ dàng hơn để thiết kế (thật dễ dàng để quên quá trình chuyển đổi trong máy tự động phức tạp) và tích hợp với các phần mềm độc lập.
• Bạn sẽ được dẫn đến thiết kế các phương thức đọc là phương pháp an toàn , dễ dàng lưu trữ và tích hợp.
• Bạn sẽ có dẫn để thiết kế phương pháp ghi như idempotent người, mà sẽ đối phó tốt hơn với timeout.

Thứ hai, HTTP-REST hoàn toàn tuân thủ HTTP (xem phần "an toàn" và "idempotent" trong phần trước), do đó bạn sẽ có thể sử dụng lại các thư viện HTTP (hiện có cho mọi ngôn ngữ hiện có) và proxy ngược HTTP, sẽ cung cấp cho bạn khả năng thực hiện các tính năng nâng cao (bộ đệm, xác thực, nén, chuyển hướng, viết lại, ghi nhật ký, v.v.) với dòng mã bằng không.

Cuối cùng nhưng không kém phần quan trọng, sử dụng HTTP làm giao thức RPC là một lỗi rất lớn theo nhà thiết kế HTTP 1.1 (và người phát minh ra REST): http://www.ics.uci.edu/~fielding/pub/dissertation/ev Assessment. htm # sec_6_5_2

Câu trả lời tuyệt vời - chỉ muốn làm rõ về một số ý kiến. JSON-RPC rất nhanh và dễ tiêu thụ, nhưng như các tài nguyên và tham số đã đề cập được kết hợp chặt chẽ và nó có xu hướng dựa vào các động từ (api / xóaUser, api / addUser) bằng cách sử dụng GET / POST trong khi REST cung cấp các tài nguyên được ghép lỏng lẻo (api / người dùng) trong API HTTP REST dựa trên một số phương thức HTTP (GET, POST, PUT, PATCH, DELETE). REST hơi khó hơn đối với các nhà phát triển thiếu kinh nghiệm để thực hiện, nhưng phong cách đã trở nên khá phổ biến hiện nay và nó cung cấp sự linh hoạt hơn nhiều trong thời gian dài (giúp API của bạn có tuổi thọ cao hơn).

Cùng với việc không có tài nguyên được liên kết chặt chẽ, REST cũng cho phép bạn tránh bị cam kết với một loại nội dung duy nhất - điều này có nghĩa là nếu khách hàng của bạn cần nhận dữ liệu bằng XML, hoặc JSON hoặc thậm chí YAML - nếu được tích hợp vào hệ thống của bạn, bạn có thể trả lại bất kỳ cái nào bằng cách sử dụng các tiêu đề loại nội dung / chấp nhận.

Điều này cho phép bạn giữ API của mình đủ linh hoạt để hỗ trợ các loại nội dung mới HOẶC yêu cầu của khách hàng.

Nhưng điều thực sự tách REST khỏi JSON-RPC là nó tuân theo một loạt các ràng buộc được suy nghĩ cẩn thận - đảm bảo tính linh hoạt của kiến ​​trúc. Các ràng buộc này bao gồm đảm bảo rằng máy khách và máy chủ có thể phát triển độc lập với nhau (bạn có thể thay đổi mà không làm hỏng ứng dụng của khách hàng), các cuộc gọi không trạng thái (trạng thái được thể hiện thông qua hypermedia), giao diện thống nhất được cung cấp cho các tương tác, API được phát triển trên một hệ thống phân lớp và phản hồi được lưu lại bởi máy khách. Ngoài ra còn có một ràng buộc tùy chọn để cung cấp mã theo yêu cầu.

Tuy nhiên, với tất cả những gì đã nói - API MOST không phải là RESTful (theo Fielding) vì chúng không kết hợp hypermedia (liên kết siêu văn bản được nhúng trong phản hồi giúp điều hướng API). Hầu hết các API bạn sẽ tìm thấy có dạng REST giống như chúng tuân theo hầu hết các khái niệm về REST, nhưng bỏ qua ràng buộc này. Tuy nhiên, ngày càng có nhiều API thực hiện điều này và nó đang trở thành một thông lệ chính.

Điều này cũng cung cấp cho bạn một số tính linh hoạt khi các API được điều khiển bằng hypermedia (như Stormpath) hướng máy khách đến các URI (có nghĩa là nếu có gì đó thay đổi, chắc chắn trường hợp bạn có thể sửa đổi URI mà không bị tác động tiêu cực), như với URI RPC được yêu cầu tĩnh. Với RPC, bạn cũng sẽ cần ghi lại rộng rãi các URI khác nhau này và giải thích cách chúng hoạt động trong mối quan hệ với nhau.

Nói chung, tôi sẽ nói REST là con đường để đi nếu bạn muốn xây dựng một API linh hoạt, có thể mở rộng, sẽ tồn tại lâu dài. Vì lý do đó, tôi sẽ nói rằng đó là con đường để đi 99% thời gian.

Chúc may mắn

IMO, điểm quan trọng là hành động so với định hướng tài nguyên. REST được định hướng tài nguyên và phù hợp với các hoạt động CRUD và do ngữ nghĩa đã biết của nó cung cấp một số dự đoán cho người dùng đầu tiên, nhưng khi được thực hiện từ các phương thức hoặc thủ tục buộc bạn phải cung cấp bản dịch nhân tạo cho thế giới tập trung tài nguyên. Mặt khác, RPC hoàn toàn phù hợp với các API hướng hành động, nơi bạn trưng bày các dịch vụ, chứ không phải các bộ tài nguyên có thể CRUD.

Không còn nghi ngờ gì nữa, REST phổ biến hơn, điều này chắc chắn sẽ thêm một số điểm nếu bạn muốn tiết lộ API cho bên thứ ba.

Nếu không (ví dụ trong trường hợp tạo giao diện AJAX trong SPA), lựa chọn của tôi là RPC. Cụ thể là JSON-RPC, kết hợp với Lược đồ JSON làm ngôn ngữ mô tả và được vận chuyển qua HTTP hoặc Websockets tùy theo trường hợp sử dụng.

JSON-RPC là một đặc tả đơn giản và thanh lịch xác định các tải trọng JSON yêu cầu và đáp ứng sẽ được sử dụng trong RPC đồng bộ hoặc không đồng bộ.

Lược đồ JSON là đặc tả dự thảo xác định định dạng dựa trên JSON nhằm mô tả dữ liệu JSON. Bằng cách mô tả các thông báo đầu vào và đầu ra dịch vụ của bạn bằng Lược đồ JSON, bạn có thể có sự phức tạp tùy ý trong cấu trúc thông báo mà không ảnh hưởng đến khả năng sử dụng và tích hợp dịch vụ có thể được tự động hóa.

Việc lựa chọn giao thức truyền tải (HTTP so với websockets) phụ thuộc vào các yếu tố khác nhau, là điều quan trọng nhất cho dù bạn cần các tính năng HTTP (bộ nhớ đệm, xác nhận lại, an toàn, idempotence, loại nội dung, nhiều phần, ...) hoặc liệu ứng dụng của bạn có cần trao đổi không tin nhắn ở mức cao.

Cho đến bây giờ rất nhiều ý kiến ​​cá nhân của tôi về vấn đề này, nhưng bây giờ một cái gì đó có thể thực sự hữu ích cho những nhà phát triển Java đang đọc những dòng này, khuôn khổ mà tôi đã làm việc trong năm ngoái, xuất phát từ cùng một câu hỏi mà bạn đang tự hỏi :

http://rpc.brutusin.org

Bạn có thể xem bản demo trực tiếp tại đây, hiển thị trình duyệt kho lưu trữ tích hợp để kiểm tra chức năng (cảm ơn Lược đồ JSON) và một loạt các dịch vụ ví dụ:

http://demo.rpc.brutusin.org

Hy vọng nó sẽ giúp bạn đời!

Nacho

Nếu dịch vụ của bạn hoạt động tốt chỉ với các mô hình và mẫu GET / POST / PUT / DELETE, hãy sử dụng REST thuần túy.

Tôi đồng ý rằng HTTP ban đầu được thiết kế cho các ứng dụng phi trạng thái.

Nhưng đối với các ứng dụng thời gian thực (web) hiện đại, phức tạp hơn (!) Nơi bạn sẽ muốn sử dụng Websockets (thường ngụ ý trạng thái), tại sao không sử dụng cả hai? JSON-RPC trên Websockets rất nhẹ nên bạn có những lợi ích sau:

• Cập nhật tức thì trên mọi máy khách (xác định cuộc gọi RPC từ máy chủ đến máy khách của bạn để cập nhật các mô hình)
• Dễ dàng thêm độ phức tạp (cố gắng tạo một bản sao Etherpad chỉ bằng REST)
• Nếu bạn làm đúng (chỉ thêm RPC dưới dạng bổ sung cho thời gian thực), hầu hết vẫn có thể sử dụng được chỉ với REST (trừ khi tính năng chính là trò chuyện hoặc một cái gì đó)

Vì bạn chỉ thiết kế API phía máy chủ, hãy bắt đầu với việc xác định các mô hình REST và sau đó thêm hỗ trợ JSON-RPC khi cần, giữ cho số lượng cuộc gọi RPC ở mức tối thiểu.

(và xin lỗi vì dấu ngoặc đơn quá lạm dụng)

Tôi đã là một fan hâm mộ lớn của REST trong quá khứ và nó có nhiều lợi thế hơn RPC trên giấy. Bạn có thể trình bày ứng dụng khách với các loại Nội dung, Bộ đệm, sử dụng lại mã trạng thái HTTP khác nhau, bạn có thể hướng dẫn khách hàng thông qua API và bạn có thể nhúng tài liệu vào API nếu nó không tự giải thích được.

Nhưng kinh nghiệm của tôi là trong thực tế, điều này không theo kịp và thay vào đó bạn làm rất nhiều việc không cần thiết để làm mọi thứ đúng. Ngoài ra, mã trạng thái HTTP thường không ánh xạ chính xác đến logic miền của bạn và sử dụng chúng trong ngữ cảnh của bạn thường cảm thấy hơi gượng ép. Nhưng điều tồi tệ nhất về REST theo ý kiến ​​của tôi là bạn dành nhiều thời gian để thiết kế tài nguyên của mình và các tương tác mà chúng cho phép. Và bất cứ khi nào bạn thực hiện một số bổ sung chính cho API của mình, bạn hy vọng bạn sẽ tìm thấy một giải pháp tốt để thêm chức năng mới và bạn đã không tự thiết kế vào một góc.

Điều này thường cảm thấy lãng phí thời gian đối với tôi vì hầu hết thời gian tôi đã có một ý tưởng hoàn toàn tốt và rõ ràng về cách mô hình hóa API như một tập hợp các cuộc gọi thủ tục từ xa. Và nếu tôi đã trải qua tất cả nỗ lực này để mô hình hóa vấn đề của mình bên trong các ràng buộc của REST, vấn đề tiếp theo là làm thế nào để gọi nó từ máy khách? Các chương trình của chúng tôi dựa trên các thủ tục gọi để xây dựng thư viện máy khách RPC tốt rất dễ dàng, xây dựng thư viện máy khách REST tốt không quá nhiều và trong hầu hết các trường hợp, bạn sẽ chỉ ánh xạ lại từ API REST trên máy chủ sang một bộ quy trình trong máy khách của mình thư viện.

Bởi vì điều này, RPC cảm thấy đơn giản và tự nhiên hơn rất nhiều đối với tôi ngày hôm nay. Điều tôi thực sự nhớ là một khung nhất quán giúp dễ dàng viết các dịch vụ RPC tự mô tả và có thể tương tác. Do đó, tôi đã tạo dự án của riêng mình để thử nghiệm các cách mới để giúp RPC dễ dàng hơn cho bản thân và có thể ai đó cũng thấy nó hữu ích: https://github.com/aheck/reflectrpc

Theo mô hình trưởng thành của Richardson , câu hỏi không phải là REST so với RPC , mà là bao nhiêu REST ?

Theo quan điểm này, việc tuân thủ tiêu chuẩn REST có thể được phân loại thành 4 cấp độ.

• mức 0: suy nghĩ về các hành động và tham số. Như bài viết giải thích, điều này về cơ bản tương đương với JSON-RPC (bài viết giải thích nó cho XML-RPC, nhưng các đối số tương tự giữ cho cả hai).
• cấp 1: suy nghĩ về mặt tài nguyên. Mọi thứ liên quan đến một tài nguyên đều thuộc về cùng một URL
• cấp 2: sử dụng động từ HTTP
• cấp 3: HATEOAS

Theo người tạo ra tiêu chuẩn REST, chỉ các dịch vụ cấp 3 mới có thể được gọi là RESTful. Tuy nhiên, đây là một thước đo về sự tuân thủ , không phải là chất lượng. Nếu bạn chỉ muốn gọi một hàm từ xa thực hiện phép tính, có lẽ sẽ không có ý nghĩa gì khi có các liên kết hypermedia có liên quan trong phản hồi, không phân biệt hành vi dựa trên động từ HTTP được sử dụng. Vì vậy, một cuộc gọi như vậy vốn có xu hướng giống RPC hơn. Tuy nhiên, mức độ tuân thủ thấp hơn không nhất thiết có nghĩa là trạng thái, hoặc khớp nối cao hơn. Có lẽ, thay vì nghĩ REST so với RPC , bạn nên sử dụng càng nhiều REST càng tốt, nhưng không còn nữa. Không xoắn ứng dụng của bạn chỉ để phù hợp với các tiêu chuẩn tuân thủ RESTful.

Tại sao JSON RPC:

Trong trường hợp API REST, chúng tôi phải xác định bộ điều khiển cho từng chức năng / phương thức mà chúng tôi có thể cần. Kết quả là nếu chúng ta có 10 phương thức mà khách hàng muốn truy cập, chúng ta phải viết 10 bộ điều khiển để giao diện yêu cầu của khách hàng với một phương thức cụ thể.

Một yếu tố khác là, mặc dù chúng tôi có các bộ điều khiển khác nhau cho từng phương thức / chức năng, khách hàng phải nhớ thời tiết để sử dụng POST hoặc GET. Điều này làm phức tạp mọi thứ hơn nữa. Trên hết để gửi dữ liệu, người ta phải đặt loại nội dung của yêu cầu nếu POST được sử dụng.

Trong trường hợp JSON RPC, mọi thứ được đơn giản hóa rất nhiều vì hầu hết các máy chủ JSONRPC hoạt động trên các phương thức POST HTTP và loại nội dung luôn là application / json. Điều này giúp bạn không phải nhớ sử dụng các cài đặt nội dung và phương thức HTTP phù hợp ở phía máy khách.

Người ta không phải tạo các bộ điều khiển riêng cho các phương thức / chức năng khác nhau mà máy chủ muốn đưa ra cho khách hàng.

Tại sao REST:

Bạn có các URL riêng cho các chức năng khác nhau mà máy chủ muốn hiển thị cho phía khách hàng. Kết quả là, bạn có thể nhúng các url này.

Hầu hết các điểm này đều gây tranh cãi và hoàn toàn phụ thuộc vào nhu cầu của một người.

Tôi nghĩ, như mọi khi, nó phụ thuộc ...

REST có lợi thế rất lớn về sự hỗ trợ công khai rộng rãi và điều này có nghĩa là rất nhiều công cụ và sách. Nếu bạn cần tạo một API được sử dụng bởi một số lượng lớn người tiêu dùng từ các tổ chức khác nhau thì đó là cách để đi chỉ vì một lý do: nó phổ biến. Là một giao thức, tất nhiên đó là một sự thất bại hoàn toàn vì có quá nhiều cách hoàn toàn khác nhau để ánh xạ một lệnh tới một URL / động từ / phản hồi.

Do đó, khi bạn viết một ứng dụng web duy nhất cần nói chuyện với phần phụ trợ thì tôi nghĩ REST quá phức tạp. Trong tình huống này, bạn không phải lo lắng về khả năng tương thích lâu dài vì ứng dụng và API có thể phát triển cùng nhau.

Tôi đã từng bắt đầu với REST cho một ứng dụng web một trang nhưng các lệnh chi tiết tốt giữa ứng dụng web và máy chủ nhanh chóng khiến tôi phát điên. Tôi có nên mã hóa nó như là một tham số đường dẫn? Trong cơ thể? Một tham số truy vấn? Một tiêu đề? Sau khi thiết kế URL / Động từ / Phản hồi, sau đó tôi phải mã hóa mớ hỗn độn này trong Javascript, bộ giải mã trong Java và sau đó gọi phương thức thực tế. Mặc dù có rất nhiều công cụ cho nó, nhưng thật khó để không có bất kỳ ngữ nghĩa HTTP nào trong mã miền của bạn, đây là một thực tế tồi. (Sự gắn kết)

Hãy thử tạo một tệp Swagger / OpenAPI cho một trang web phức tạp trung bình và so sánh nó với một giao diện Java duy nhất mô tả các quy trình từ xa trong tệp đó. Sự gia tăng phức tạp là đáng kinh ngạc.

Do đó, tôi đã chuyển từ REST sang JSON-RPC cho ứng dụng web một trang. aI đã phát triển một thư viện nhỏ mã hóa giao diện Java trên máy chủ và chuyển nó đến trình duyệt. Trong trình duyệt, điều này đã tạo một proxy cho mã ứng dụng trả lại lời hứa cho từng chức năng.

Một lần nữa, REST có vị trí của nó chỉ vì nó nổi tiếng và do đó được hỗ trợ tốt. Nó cũng quan trọng để nhận ra triết lý tài nguyên phi trạng thái cơ bản và mô hình phân cấp. Tuy nhiên, những nguyên tắc này có thể dễ dàng được sử dụng trong mô hình RPC. JSON RPC hoạt động trên HTTP nên nó có cùng lợi thế của REST trong lĩnh vực này. Sự khác biệt là khi bạn chắc chắn chạy vào các chức năng này không phù hợp với các nguyên tắc này, bạn không bị buộc phải làm nhiều việc không cần thiết.

REST được kết hợp chặt chẽ với HTTP, vì vậy nếu bạn chỉ hiển thị API của mình qua HTTP thì REST phù hợp hơn với hầu hết các trường hợp (nhưng không phải tất cả). Tuy nhiên, nếu bạn cần đưa API của mình lên các phương tiện vận chuyển khác như nhắn tin hoặc ổ cắm web thì REST không thể áp dụng được.

Sẽ tốt hơn nếu chọn JSON-RPC giữa REST và JSON-RPC để phát triển API cho ứng dụng web dễ hiểu hơn. JSON-RPC được ưa thích vì có thể dễ dàng hiểu được ánh xạ tới các cuộc gọi phương thức và truyền thông.

Chọn cách tiếp cận phù hợp nhất phụ thuộc vào các ràng buộc hoặc mục tiêu chính. Ví dụ, đối với hiệu suất là một đặc điểm chính, nên sử dụng JSON-RPC (ví dụ: Tính toán hiệu suất cao). Tuy nhiên, nếu mục tiêu chính là bất khả tri để đưa ra một giao diện chung được suy luận bởi những người khác, thì nên đi đến REST. Nếu cả hai mục tiêu của bạn là cần thiết để đạt được, nên bao gồm cả hai giao thức.

Điều thực sự phân tách REST khỏi JSON-RPC là nó kéo theo một loạt các ràng buộc được suy nghĩ cẩn thận - xác nhận tính linh hoạt của kiến ​​trúc. Các ràng buộc đảm bảo rằng máy khách cũng như máy chủ có thể phát triển độc lập với nhau (có thể thực hiện các thay đổi mà không gây rối với ứng dụng của máy khách), các cuộc gọi không trạng thái (trạng thái được coi là hypermedia), thống nhất giao diện được cung cấp cho các tương tác, API được nâng cao trên hệ thống lớp (Hall, 2010). JSON-RPC rất nhanh và dễ tiêu thụ, tuy nhiên, như các tài nguyên được đề cập cũng như các tham số được liên kết chặt chẽ và có thể phụ thuộc vào các động từ (api / addUser, api / xóaUser) bằng cách sử dụng GET / POST trong khi REST cung cấp các tài nguyên được ghép lỏng lẻo (api / người dùng) trong HTTP. API REST phụ thuộc vào một số phương thức HTTP như GET, PUT, POST, DELETE, PATCH.

JSON (được ký hiệu là Ký hiệu đối tượng JavaScript) là định dạng trao đổi dữ liệu nhẹ, dễ dàng cho con người đọc cũng như viết. Nó là rắc rối miễn phí cho máy phân tích và tạo. JSON là một định dạng văn bản hoàn toàn độc lập với ngôn ngữ nhưng thực hiện các quy ước quen thuộc với các lập trình viên của họ ngôn ngữ, bao gồm C #, C, C ++, Java, Perl, JavaScript, Python và nhiều quy tắc khác. Các thuộc tính như vậy làm cho JSON trở thành một ngôn ngữ trao đổi dữ liệu hoàn hảo và là lựa chọn tốt hơn để lựa chọn.

Câu hỏi sai: áp đặt một manichean không tồn tại!

Bạn có thể sử dụng JSON-RPC với "ít động từ" (không có phương thức ) và duy trì tiêu chuẩn hóa tối thiểu cần thiết cho id sendo, tham số, mã lỗi và thông báo cảnh báo . Tiêu chuẩn JSON-RPC không nói "bạn không thể là REST", chỉ nói cách đóng gói thông tin cơ bản.

"REST JSON-RPC" tồn tại ! là REST với "thực tiễn tốt nhất", để đóng gói thông tin tối thiểu, với các hợp đồng đơn giản và vững chắc.

Thí dụ

(từ câu trả lời này và bối cảnh mô phạm)

Khi giao dịch với REST, thường giúp bắt đầu bằng cách suy nghĩ về các tài nguyên. Trong trường hợp này, tài nguyên không chỉ là "tài khoản ngân hàng" mà là giao dịch của tài khoản ngân hàng đó ... Nhưng JSON-RPC không bắt buộc tham số "phương thức", tất cả được mã hóa theo "đường dẫn" của điểm cuối.

• REST của tiền gửi với POST /Bank/Account/John/Transactionvới yêu cầu JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  Phản hồi JSON có thể là một cái gì đó như{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST rút tiền với POST /Bank/Account/John/Transaction... tương tự.

• ... GET /Bank/Account/John/Transaction/12345@13... Điều này có thể trả về một bản ghi JSON của giao dịch chính xác đó (ví dụ: người dùng của bạn thường muốn có bản ghi ghi nợ và tín dụng trên tài khoản của họ). Một cái gì đó như {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. Quy ước về yêu cầu GET (REST) ​​có thể bao gồm mã hóa id theo "@id", do đó không cần gửi bất kỳ JSON nào, nhưng vẫn sử dụng JSON-RPC trong gói phản hồi.

Nếu bạn yêu cầu tài nguyên, thì API RESTful sẽ tốt hơn theo thiết kế. Nếu bạn yêu cầu một số dữ liệu phức tạp với nhiều tham số và phương thức phức tạp khác với CRUD đơn giản, thì RPC là cách phù hợp.

Tôi sử dụng vdata cho giao thức RPC: http://vdata.dekuan.org/

1, PHP và JavaScript đều ổn. 2, Cuộc gọi chia sẻ tài nguyên nguồn gốc chéo (CORS) vẫn ổn.