REST có phải là lựa chọn tốt cho các ứng dụng web GUI không?

Question

Các ứng dụng web dựa trên GUI có thể được xây dựng dựa trên thành phần GUI, khung trạng thái như Wicket hoặc chúng có thể xây dựng theo cách không có trạng thái RESTful, trạng thái GUI chỉ trên máy khách.

Từ quan điểm kỹ thuật, REST trông giống như đúng cách vì nó tận dụng toàn bộ sức mạnh của http và dẫn đến các ứng dụng có khả năng mở rộng cao. Nhưng điều đó có giá. GUI phức tạp sẽ yêu cầu một ứng dụng JavaScript trên máy khách trong nhiều trường hợp. Bạn phải ở lại trên cùng một trang và tải lại chỉ các phần, nếu nhà nước nên được duy trì trên máy khách. Hoặc bạn phải sử dụng các thủ thuật với khung nội tuyến ẩn. Đôi khi có tài nguyên giả như giỏ mua hàng trên máy chủ, để kích hoạt thiết kế RESTful. Bạn phải duy trì trạng thái trung gian của các cuộc đối thoại nhiều bước và như vậy ...

Nếu tôi nhìn xung quanh, có rất ít ứng dụng web RESTful GUI. Đây có phải là vì lý do lịch sử hay là một thiết kế RESTful không có hiệu quả trong các tình huống phổ biến?

Answer 1

Thiết kế GUI yên tĩnh rất hiệu quả, IMHO. Bạn có thể tận dụng rất nhiều chức năng mà không cần thêm công việc để hỗ trợ các trường hợp góc, chẳng hạn như người dùng gửi lại thông tin, lịch sử trình duyệt (quay lại và chuyển tiếp) nhiều tab và cửa sổ. Nếu tôi không nhầm trang web này sử dụng giao diện người dùng RESTful.

Answer 2

REST được xác định bằng cách quan sát đặc điểm của các ứng dụng web thành công, cả GUI và M2M. Do đó theo định nghĩa, nó phải phù hợp cho những trường hợp này.

Tôi cũng nhận thấy bạn đã đặt câu hỏi liên quan đến desktop versus web applications. Bạn có thể muốn biết rằng REST là một kiến ​​trúc tuyệt vời để xây dựng các ứng dụng máy khách trên máy tính để bàn. Tôi đã viết một vài máy trạm để có được tất cả dữ liệu của họ từ một máy chủ REST.

Answer 3

Nếu tôi nhìn xung quanh, có rất ít Ứng dụng web GUI yên tĩnh. Đây có phải là vì lý do lịch sử hay là Thiết kế RESTful không có hiệu quả trong các trường hợp phổ biến ?

câu trả lời của tôi là chủ quan, nhưng theo ý kiến ​​của tôi, hai rào cản lớn cản trở sự phát triển RESTful:

1. Thay đổi - nó rất khác so với cách các trang web được thiết kế theo truyền thống
2. Challenge - thiết kế một tinh khiết RESTful API máy chủ và giao diện người dùng khách hàng phong phú, tương ứng không dễ dàng

GUI phức tạp sẽ yêu cầu JavaScript ứng dụng trên máy khách trong nhiều trường hợp .

Theo tôi, một phức tạp, một trải nghiệm phía khách hàng phong phú sẽ yêu cầu một số JavaScript chuyên sâu, bất kể triển khai phía máy chủ.

Bạn phải ở lại trên cùng một trang và tải lại chỉ phần,

Đây là một thiết kế rất khác biệt so với truyền thống yêu cầu/đáp ứng đầy đủ trang-to-đầy đủ trang thiết kế. Mỗi thiết kế đều có các giao dịch riêng. Các thiết kế REST hoạt động tốt với các cuộc gọi AJAX, nhưng mã phía máy khách yêu cầu thiết kế cẩn thận để duy trì và mạnh mẽ.

Một máy chủ RESTful với một dày-client:

• quy mô cũng như: thông tin phiên cho mỗi người dùng không được lưu trữ trong bộ nhớ máy chủ khan hiếm
dữ liệu
• ít request/response qua dây: không gửi mỗi trang đầy đủ, không gửi ID phiên hoặc ViewState s
• URL có thể sử dụng lại sạch sẽ: cung cấp API máy chủ sạch, được tách riêng có thể hỗ trợ nhiều giao diện người dùng
• tinh khiết: tuân thủ nghiêm ngặt đặc điểm HTTP (KHÔNG gây tác dụng phụ, v.v.)
• kinh nghiệm khách hàng: phong phú hơn, phản ứng nhanh hơn với các giao dịch không đồng bộ

Tuy nhiên, như bạn đề cập đến dày-khách hàng có nhiều nhược điểm:

• dễ bị tấn công XSS, URL RESTful thực sự cần bảo mật cẩn thận
• JavaScript phức tạp có thể khó khăn để phát triển, duy trì và gỡ lỗi (sử dụng OO JavaScript có thể giúp dàn xếp điều này)
• cần phải chỉ ra cho người dùng rằng các yêu cầu không đồng bộ là processi ng trong nền
hơn
• client-side Logic suy xử lý là cần thiết
• khuôn khổ và các công cụ IDE đã theo truyền thống yếu cho sự phát triển client-side, so với server-side (điều này đang dần trở nên tốt hơn)