Khi nào thì cách tiếp cận RPC-ish phù hợp hơn REST?

Sau khi xem bài nói chuyện này về REST, Reuse và Serendipity của Steve Vinoski, tôi tự hỏi liệu có trường hợp kinh doanh nào trong các dự án Greenfield cho các thiết lập RPC-ish, mà REST không thể giải quyết theo cách tốt hơn.

Một vài vấn đề RPC mà ông đề cập:

• Tập trung vào ngôn ngữ (phù hợp với hệ thống phân tán với ngôn ngữ, không phải theo cách khác)
• "Làm cho nó trông cục bộ" (và đối phó với thất bại và độ trễ là ngoại lệ thay vì quy tắc)
• dự định độc lập với ngôn ngữ, nhưng vẫn có "chức năng gọi" trên các ngôn ngữ làm thành phần chính
• IDL nồi hơi
• Ảo tưởng về loại an toàn
• và một vài ...

Chỉ cần kịch tính hóa nó một chút, một số kết quả Google Instant cho RPC vs REST:

Nói chung, RPC cung cấp tích hợp ngôn ngữ nhiều hơn nhiều so với REST. Như bạn đã đề cập, điều này đi kèm với một số vấn đề về quy mô, xử lý lỗi, an toàn loại, v.v., đặc biệt khi một hệ thống phân tán duy nhất liên quan đến nhiều máy chủ chạy mã được viết bằng nhiều ngôn ngữ. Tuy nhiên, sau khi có các hệ thống kinh doanh bằng văn bản sử dụng RPC, REST và thậm chí cả hai cùng một lúc, tôi đã thấy rằng có một số lý do chính đáng để chọn RPC thay vì REST trong một số trường hợp nhất định.

Đây là trường hợp tôi thấy RPC phù hợp hơn:

• Khớp nối chặt chẽ. Các thành phần (phân tán) của hệ thống được thiết kế để hoạt động cùng nhau và việc thay đổi một thành phần có thể sẽ tác động đến tất cả các thành phần khác. Không chắc là các thành phần sẽ phải được điều chỉnh để giao tiếp với các hệ thống khác trong tương lai.
• Giao tiếp đáng tin cậy. Các thành phần sẽ liên lạc với nhau hoàn toàn trên cùng một máy chủ hoặc trên mạng không có khả năng gặp sự cố về độ trễ, mất gói, v.v. (Điều này vẫn có nghĩa là bạn cần thiết kế hệ thống của mình để xử lý các trường hợp này, tuy nhiên.)
• Ngôn ngữ thống nhất. Tất cả (hoặc chủ yếu là tất cả) các thành phần sẽ được viết bằng một ngôn ngữ. Không chắc là các thành phần bổ sung được viết bằng một ngôn ngữ khác sẽ được thêm vào trong tương lai.

Liên quan đến điểm về IDL, trong hệ thống REST, bạn cũng phải viết mã chuyển đổi dữ liệu trong các yêu cầu và phản hồi REST thành bất kỳ biểu diễn dữ liệu nội bộ nào bạn đang sử dụng. Các nguồn IDL (có nhận xét tốt) cũng có thể đóng vai trò là tài liệu của giao diện, phải được viết và duy trì riêng cho API REST.

Ba mục trên thường xảy ra khi bạn đang tìm cách xây dựng một thành phần của một hệ thống lớn hơn. Theo kinh nghiệm của tôi, các thành phần này thường là những thành phần mà hệ thống con của chúng cần có khả năng thất bại độc lập và không gây ra sự thất bại hoàn toàn của các hệ thống con khác hoặc toàn bộ thành phần. Nhiều hệ thống được viết bằng Erlang để hoàn thành các mục tiêu này và trong một số trường hợp, Erlang có thể là lựa chọn tốt hơn so với viết hệ thống bằng ngôn ngữ khác và sử dụng RPC chỉ để đạt được những lợi ích này.

Giống như hầu hết các vấn đề kỹ thuật, không có một giải pháp duy nhất nào cho vấn đề giao tiếp giữa các quá trình. Bạn cần nhìn vào hệ thống bạn đang thiết kế và đưa ra lựa chọn tốt nhất cho trường hợp sử dụng của bạn.

Có một số lợi thế chính của REST khi các sản phẩm được mở rộng qua trung tâm dữ liệu và bạn đang thực hiện tính sẵn sàng cao và cân bằng tải.

Tuy nhiên, hãy nghĩ về một dự án quy mô nhỏ hơn. Cần một dịch vụ web sẽ có vài trăm yêu cầu một giờ? WCF giải quyết tất cả các vấn đề giao thông. Có giao diện thuận tiện để gửi các đối tượng qua mạng và cho phép kết nối mạng được định cấu hình, mã hóa và chứng nhận không có lập trình bằng cách chỉ sử dụng tệp application.config.

Bạn thực sự có thể có cả hai. Các plugin như RestRPC cho Grails cung cấp các chú thích sẽ chặn các cuộc gọi đến các phương thức của bạn và xử lý chúng một cách cẩn thận trong khi cho phép bạn có nhiều như bạn muốn (sẽ rất giống RPC).