REST vs RPC để phát triển di động

Như nhiều người biết, sự phát triển di động đang tăng vọt trong những ngày này và, tôi tin rằng, nó ảnh hưởng đến những gì chúng ta viết mã. Để cụ thể, tôi quan tâm đến việc phát triển các dịch vụ web cho một ứng dụng di động.

Tôi thấy hai kiến ​​trúc có thể - RPC và REST. Tôi đã phát triển cả hai dịch vụ REST và RPC và điều tôi nhận thấy là các dịch vụ RPC dễ viết mã hơn, đặc biệt là trong các ngôn ngữ như PHP. Vấn đề với nó dường như là khả năng mở rộng - phía máy chủ có thể dễ dàng biến thành một mớ hỗn độn khi có nhiều thủ tục.

Mặt khác, REST dường như có cấu trúc hơn rất nhiều, phía máy chủ trở nên tương đối dễ bảo trì nhưng nó có khả năng phá vỡ dữ liệu thành nhiều tài nguyên có hại cho các ứng dụng di động (vì nhiều lý do).

Từ những gì tôi đã trải nghiệm, RPC có vẻ tốt hơn một chút trong hầu hết các trường hợp:

• Cả hai phía khách hàng và máy chủ đều quan tâm đến việc giảm thiểu số lượng thủ tục có sẵn và các cuộc gọi được thực hiện.
• Theo quy tắc kiến ​​trúc không đối phó với tối ưu hóa có thể.

Tôi không thực sự mong đợi ai đó giải thích cho tôi REST và RPC là gì, web chứa đầy điều đó. Tôi muốn những người có kinh nghiệm phát triển ứng dụng di động bày tỏ ý kiến ​​của họ về việc sử dụng hai kiến ​​trúc này ở phía máy chủ. Lời khuyên cũng được hoan nghênh (ai không thích mẹo, hả?).

Có rất ít sự khác biệt, RPC có xu hướng nhiều giao thức nhị phân hơn REST, nhưng đó không phải là trường hợp. Ngoài ra RPC có xu hướng được triển khai như một điểm thủ tục duy nhất cho mỗi cuộc gọi, nhưng một lần nữa không cần phải như vậy - bạn có thể thực hiện một quy trình RPC duy nhất lấy động từ kiểu REST làm đối số đầu tiên. RPC đôi khi có cách tiếp cận bán / trạng thái, nhưng một lần nữa, đó không phải là trường hợp nếu bạn chuyển qua 'cookie' với mỗi cuộc gọi.

Ngày nay, tất cả bắt nguồn từ hỗ trợ phát triển và có nhiều API REST hơn cho các ngôn ngữ dựa trên web và vì vậy mọi người sử dụng REST. Nếu bạn đang có một cái nhìn tập trung vào người dùng hơn, thì có lẽ bạn nên sử dụng cơ chế RPC tốt hơn, tận dụng tính linh hoạt để cung cấp giao thức nhị phân nén hơn, sau đó thực hiện theo cách bạn muốn - thủ tục đơn lẻ định tuyến đến một thói quen dựa trên id hoặc 'động từ' và hoàn toàn không trạng thái bằng cách chuyển id. Tất cả điều này có thể được thực hiện để trông rất giống REST nhưng với chi phí thấp hơn đáng kể.

Có một số hệ thống RPC, hãy thử bộ đệm giao thức hoặc tiết kiệm cho ứng dụng di động của bạn.

Bạn có thể muốn xem bài viết này của Netflix về thiết kế lại API của họ: http://techblog.netflix.com/2012/07/embraces-differences-inside-netflix.html

TL; DR:

• Nói chung, REST gây ra các API trò chuyện: nếu một thao tác cần thao tác nhiều tài nguyên, bạn sẽ cần nhiều cuộc gọi (ví dụ: chậm!)
• Một API không ánh xạ tốt đến những người tiêu dùng khác nhau, đó là lý do tại sao Netflix chuyển một số mã máy khách sang máy chủ: mỗi người tiêu dùng có thể cung cấp lớp bộ điều hợp / bộ điều phối riêng trên máy chủ để tối ưu hóa quyền truy cập API cho những người tiêu dùng khác nhau.

Ghi chú cá nhân:

• Vui lòng không liên kết RPC với các giao thức cồng kềnh doanh nghiệp SOAP / CORBA / RMI kiểu cũ. Ví dụ JSON-RPC là một giao thức rất đơn giản, thanh lịch và nhanh nhẹn để thực hiện RPC mà bạn chắc chắn nên xem xét.
• REST hoàn hảo cho CRUD API. Tuy nhiên, nếu API của bạn rất thiên về hành động, bạn có thể thấy khó xử khi ánh xạ nó lên các động từ / điểm cuối REST.