Tại sao REST thường được sử dụng thay vì các cơ chế giống RPC trong các ứng dụng web?

Gần đây tôi đã bắt đầu tại một công ty sử dụng khung tùy chỉnh khá bất thường cho các ứng dụng web của họ, ít nhất là so với các khung ứng dụng web thông thường mà tôi biết. Thay vì một dịch vụ web RESTful, một cơ chế RPC được sử dụng để giao tiếp với máy chủ.

Giao tiếp với máy chủ trông giống như một cuộc gọi chức năng đơn giản, nhưng chức năng được thực thi trên máy chủ chứ không phải máy khách. Về phía máy chủ, có một cách để xác định chức năng nào mà máy khách có thể gọi. Các chi tiết về cách dịch này thành các yêu cầu http được tóm tắt hoàn toàn.

Tôi mới chỉ sử dụng nó trong một thời gian ngắn, nhưng nó có vẻ khá thuận tiện. Nhưng tôi đang tự hỏi những nhược điểm của phương pháp này tôi đang thiếu. Mọi người khác dường như đang làm điều đó khác đi, đó thường là một dấu hiệu cho tôi rằng tôi có thể đang làm điều gì đó ngu ngốc hoặc xuất sắc, với tỷ lệ cược cao hơn nhiều so với trước đây.

REST được thiết kế cho web và web được thiết kế cho REST. Hai người chỉ cần phù hợp với nhau. Luận án tiến sĩ năm 2000 của Roy Fielding Phong cách kiến ​​trúc và Thiết kế Kiến trúc phần mềm dựa trên mạng đã xác định và giới thiệu thuật ngữ REST , và có sự tương tác đáng kể giữa web và REST: Roy Fielding làm việc trên HTTP / 1.1, trong đó ông là tác giả chính, và ông đã sử dụng những gì ông học được ở đó để mô tả REST trong luận án của mình.

Vì vậy, lý do đơn giản khiến web và REST kết hợp rất tốt là định nghĩa của REST được trích xuất từ ​​cách thức hoạt động của web và web là một triển khai của REST.

Đó là lý do tại sao REST phù hợp với các dịch vụ web và ứng dụng web: bởi vì bạn chỉ cần làm những việc tương tự đã được chứng minh là hoạt động trong web "con người" và áp dụng chúng vào web "máy".

Các lớn vấn đề với RPC (tùy thuộc vào chính xác thực hiện) nằm về cơ bản trong sai lầm của Distributed Computing , được giải thích chi tiết hơn trong này whitepaper bởi Arnon Rotem-Gal-Oz :

1. Mạng là đáng tin cậy
2. Độ trễ bằng không
3. Băng thông là vô hạn
4. Mạng được bảo mật
5. Cấu trúc liên kết không thay đổi
6. Có một quản trị viên
7. Chi phí vận chuyển bằng không
8. Mạng là đồng nhất

Đây là tất cả các giả định mà người mới tham gia thường đưa ra khi họ bắt đầu tạo các hệ thống phân tán. Tất nhiên, tất cả chúng đều sai. Và bạn cần tính đến tất cả chúng khi tạo các hệ thống phân tán.

Vấn đề với nhiều triển khai RPC là họ cố gắng thực hiện các cuộc gọi từ xa trông giống như các cuộc gọi nội hạt. Nhưng chúng không có gì giống nhau:

• một cuộc gọi địa phương không bao giờ thất bại; các chương trình con mà bạn gọi là có thể thất bại, nhưng các cuộc gọi riêng của mình không bao giờ làm - một cuộc gọi từ xa có thể bị lạc trên mạng
• một cuộc gọi địa phương là tức thời; các chương trình con mà bạn gọi là có thể chạy trong một thời gian dài (hoặc thậm chí vĩnh viễn nếu nó được bị mắc kẹt trong một vòng lặp vô hạn), nhưng các cuộc gọi tự mất không có thời gian ở tất cả (tốt, một số ít các hướng dẫn CPU nhiều nhất, ít nếu cuộc gọi là nội tuyến, nhưng nó rất nhanh) - một cuộc gọi từ xa có thể bị kẹt trên mạng trong một thời gian dài
• nếu chương trình con trả về bình thường, kết quả luôn quay trở lại - với một cuộc gọi từ xa, kết quả có thể bị mất trên mạng
• trả về là tức thời - kết quả từ xa có thể đi trên mạng trong một thời gian dài
• nếu tôi gọi chương trình con một lần, nó sẽ chạy chính xác một lần - một cuộc gọi từ xa có thể bị mất trên mạng hoặc bị trùng lặp để thói quen từ xa có thể chạy trong khoảng từ 0 đến bất kỳ số lần nào
• Tôi lấy lại chính xác một kết quả - một kết quả từ xa có thể bị mất hoặc trùng lặp, do đó bạn có thể nhận được kết quả 0 lần trở lên
• nếu tôi gọi chương trình con hai lần, tôi nhận được hai kết quả và tôi nhận được kết quả của cuộc gọi đầu tiên trước kết quả của cuộc gọi thứ hai - bây giờ bạn có thể đoán nó: với RPC, bạn có thể không nhận được kết quả nào, hoặc chỉ có kết quả đầu tiên , hoặc chỉ lần thứ hai, hoặc lần thứ hai trước lần đầu tiên, hoặc lần đầu tiên có thể bị mất và bạn nhận được lần thứ hai, hoặc ngược lại, v.v.
• nếu tôi gọi avà sau đó b, tôi nhận lại kết quả avà sau đó là kết quả của b - đây chỉ là phiên bản chung hơn của điểm trước đó, với RPC, bạn có thể nhận được bất kỳ câu trả lời nào trong hai câu trả lời 0 lần trở lên theo bất kỳ thứ tự nào

Bạn sẽ phải đối phó với tất cả những điều trên cho một cuộc gọi từ xa. Nhưng nếu khuôn khổ của bạn làm cho các cuộc gọi từ xa không thể phân biệt từ các cuộc gọi địa phương, sau đó bạn có thể không , bởi vì bạn không biết cái nào là các cuộc gọi từ xa. Khung có thể thử và xử lý tất cả những thứ đó cho bạn, nhưng vấn đề là: khung không biết nhiều về hệ thống của bạn như bạn làm. Nó không biết liệu có những cuộc gọi mà thực sự không thành vấn đề nếu một lần bị lạc. Vì vậy, khung phải rất phòng thủ, và điều đó rất tốn kém về độ trễ và băng thông.

Đặc biệt là vì khuôn khổ thực sự không thể bảo vệ bạn. Các CAP Định lý nói rằng một hệ thống phân phối không thể nhất quán, có sẵn, và phân vùng-Có khả năng cùng một lúc; chính xác hơn, nó nói rằng một khi phân vùng xảy ra, hệ thống không thể tiếp tục là nhất quán và có sẵn, nó phải chọn một (trái với niềm tin phổ biến, định lý không nói rằng bạn không thể có cả ba, khi hệ thống đang chạy thông thường, bạn có thể có cả ba, nhưng một khi bạn có Phân vùng, bạn phải chọn một trong hai cái còn lại). Các PACELC Định lý mở rộng CAP Định lý bằng cách hiển thị mà ngay cả khi hệ thống đang làm việc, bạn phải thương mại-off trễ so với quán.

Đây là những sự đánh đổi quan trọng mà khung công tác gần như không thể bảo vệ bạn, vì chúng đặc trưng cho miền và quan trọng đối với thiết kế cốt lõi.

Ngược lại điều này với một cách tiếp cận như Erlang, mà làm việc: trong Erlang, tất cả các thông điệp sẽ gửi được coi là từ xa, ngay cả khi họ ở địa phương. Điều này có nghĩa là bạn luôn sẵn sàng đối phó với tất cả các vấn đề trên (và nhiều vấn đề khác). Đối với các quá trình địa phương, những gì đặt ra một chút một trên không, mặc dù. Để giúp với điều này, có rất nhiều công cụ, khung, thư viện, mẫu và thành ngữ để xử lý việc xử lý và giám sát lỗi.

Bạn chưa mô tả cụ thể khung RPC của bạn hoạt động như thế nào và ngôn ngữ hoặc thư viện bạn đang sử dụng, nhưng tôi nghi ngờ rằng nó thuộc loại "giả vờ mạng không tồn tại" trước đây. Những người không làm việc. Bạn có thể xóa bỏ sự khác biệt giữa các cuộc gọi từ xa và cục bộ bằng cách coi mọi thứ là một cuộc gọi từ xa . Làm theo cách khác xung quanh trừu tượng quá nhiều: mạng là một phần của hệ thống của bạn, nếu bạn trừu tượng hóa nó đi, bạn trừu tượng đi một cái gì đó mà bạn thực sự cần biết.

Bây giờ, cho dù bạn có phải sử dụng REST cụ thể hay không, đó là một câu hỏi hoàn toàn khác. Như tôi đã giải thích ở trên, web được thiết kế cho REST và REST được thiết kế cho web, vì vậy hai cái này có ý nghĩa với nhau, nhưng bạn có thể sử dụng các kiểu kiến ​​trúc khác, nếu bạn muốn. Nhưng ít nhất một phần câu hỏi của bạn là về "tại sao không phải RPC", và tôi đã nêu ra những lý do trên, chính xác hơn là tôi đã giải thích lý do tại sao loại RPC mà tôi nghi ngờ bạn đang sử dụng có thể khiến bạn gặp rắc rối.

Đã có một vài ý tưởng hay trong các bình luận, mà tôi sẽ nhắc lại ở đây:

1. RPC thường là công nghệ cụ thể.
2. Điều mà các nhà phát triển chủ yếu quan tâm là JSON, không phải REST.

JSON có một số phẩm chất rất tốt đẹp. Nó đơn giản, dễ đọc đối với con người, dễ dàng cho máy tính phân tích cú pháp và Javascript ngay lập tức nhận ra nó một cách tự nhiên (đó là, bạn biết, ký hiệu đối tượng Javascript ).

Nếu bạn sẵn sàng từ bỏ các ràng buộc như REST, bạn có thể thực hiện hầu hết mọi thứ bạn muốn với JSON, bao gồm các cuộc gọi thủ tục từ xa. Tất cả bạn phải làm là thiết lập một giao thức phù hợp. Trong thực tế, một giao thức như vậy đã tồn tại: JSON-RPC.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

RPC và REST chỉ là những cách tiếp cận khác nhau với ưu và nhược điểm và cả hai đều có giá trị tùy thuộc vào ngữ cảnh. 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. Các máy khách RPC kết hợp chặt chẽ với 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.