Giao tiếp thời gian thực dựa trên web có tương thích với mô hình REST không?

Question

Các ứng dụng web trải qua một sự thay đổi mô hình tuyệt vời trong những năm qua.

Một thập kỷ trước (và không may là ngày nay), các ứng dụng web chỉ sống ở các máy chủ nặng, xử lý mọi thứ từ dữ liệu sang định dạng bản trình bày và gửi cho khách hàng câm.

Sau đó, AJAX tham gia trò chơi và ứng dụng web bắt đầu biến thành thứ gì đó sống giữa máy chủ và trình duyệt.

Trong giai đoạn cao điểm của AJAX, logic ứng dụng web bắt đầu xuất hiện hoàn toàn trên trình duyệt. Tôi nghĩ rằng đây là khi HTTP RESTful API bắt đầu xuất hiện. Đột nhiên, mọi dịch vụ mới đều có các loại loại RESTful API của chúng tôi và các khung công tác JavaScript MV đột nhiên bắt đầu xuất hiện như bỏng ngô. Việc sử dụng các thiết bị di động cũng tăng lên rất nhiều và REST chỉ phù hợp với các loại kịch bản này. Tôi nói "loại RESTful" ở đây vì hầu như mọi API đều tuyên bố là REST, không phải. Nhưng đó là một câu chuyện hoàn toàn khác.

Thực tế, tôi đã trở thành một "nhà truyền giáo REST REST".

Khi tôi nghĩ rằng các ứng dụng web không thể phát triển nhiều hơn nữa, một kỷ nguyên mới có vẻ như đang diễn ra: Các ứng dụng web kết nối liên tục có trạng thái. Meteor là một ví dụ về khung làm việc tuyệt vời của loại ứng dụng đó. Sau đó, tôi thấy điều này video. Trong video này, Matt Debergalis nói về Meteor và cả hai đều làm một công việc tuyệt vời! Tuy nhiên, ông là loại đưa xuống API REST cho loại mục đích này ủng hộ các kết nối thời gian thực liên tục.

Tôi rất muốn có các bản cập nhật mô hình thời gian thực, ví dụ, nhưng vẫn có tất cả sự tuyệt vời của REST. Streaming API của API có vẻ như những gì tôi cần (ví dụ như firehose.io và Twitter), nhưng có rất ít thông tin về loại API mới này.

Vì vậy, câu hỏi của tôi là:

là giao tiếp thời gian thực dựa trên web không tương thích với REST mô?

(Xin lỗi vì sự văn bản giới thiệu dài, nhưng tôi nghĩ rằng câu hỏi này sẽ chỉ có ý nghĩa với một số ngữ cảnh)

Answer 1

kết nối tcp/ip dai dẳng Stateful cho các ứng dụng web là rất lớn, miễn là bạn không di chuyển xung quanh.

Tôi đã phát triển khung thời gian thực dựa trên web và theo kinh nghiệm của mình, tôi thấy rằng khi sử dụng trình duyệt web trên thiết bị di động, địa chỉ IP luôn thay đổi khi tôi chuyển từ tháp này sang tháp khác, hoặc wi-fi -fi.

Khi địa chỉ IP tiếp tục thay đổi, khái niệm rằng đó là kết nối liên tục bốc hơi khá nhanh.

Khuôn khổ cho ứng dụng web trong thời gian thực phải được kiến ​​trúc với giả định rằng các kết nối sẽ tạm thời và khung phải thực hiện khái niệm riêng của phiên trong khi kết nối IP cơ bản đến back-end tiếp tục thay đổi.

Sau khi phiên được xác định và sử dụng trong tất cả các yêu cầu và phản hồi giữa khách hàng và máy chủ, một phiên bản về cơ bản có 'kết nối web'. Và bây giờ, người ta có thể phát triển các ứng dụng dựa trên web theo thời gian thực bằng cách sử dụng mô hình REST.

Máy chủ back-end của khung phải thông minh để xếp hàng cập nhật trong khi địa chỉ IP đang trải qua quá trình chuyển đổi và sau đó đồng bộ hóa khi kết nối tcp/ip đã được thiết lập lại.

Câu trả lời ngắn gọn là 'Có, bạn có thể làm ứng dụng dựa trên web theo thời gian thực bằng cách sử dụng mô hình REST'.

Nếu bạn muốn chơi với một, hãy cho tôi biết.

Answer 2

Tôi cũng rất quan tâm đến chủ đề này. bài này có một số liên kết đến các giấy tờ mà thảo luận về một số rắc rối với RPC được thiết kế kém:

http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html

tôi không nói Meteor được thiết kế kém, bởi vì tôi không biết nhiều về Meteor.

Trong mọi trường hợp, tôi nghĩ tôi muốn điều tốt nhất của cả hai "thế giới". Tôi muốn hưởng lợi từ REST và tất cả những gì nó liên quan đến giao diện chung chung, địa chỉ, trạng thái không quốc tịch, v.v.

Và tôi cũng không muốn bị bỏ lại trong cuộc cách mạng web "thời gian thực" này! Nó chắc chắn rất tuyệt vời.

Tôi tự hỏi nếu không có một phương pháp lai có thể làm việc:

điểm cuối RESTful có thể cho phép một khách hàng bước vào một không gian, và làm theo các liên kết đến các tài liệu liên quan như HATEOAS đòi hỏi. Tuy nhiên, đối với "luồng cập nhật" đối với tài nguyên, có lẽ "tên đăng ký" có thể là URI, khi được duyệt theo yêu cầu duy nhất theo thời gian, như thông qua thanh địa chỉ hoặc curl của trình duyệt web, sẽ trả về một trong hai biểu diễn của "trạng thái hiện tại", hoặc danh sách các liên kết với href cho các trạng thái trước của tài nguyên và/hoặc một cách để truy vấn các "sự kiện" rời rạc đã xảy ra đối với đối tượng. Bằng cách này, nếu bạn nói với "phiên bản 1" của thực thể, và sau đó phát lại từng sự kiện chống lại nó, bạn có thể biến nó thành "trạng thái hiện tại" của nó, và các sự kiện này có thể được truyền trực tiếp vào một khách hàng không muốn nhận được các đại diện hoàn chỉnh chỉ vì một phần nhỏ của một thực thể đã thay đổi. Điều này về cơ bản là khái niệm về một "cửa hàng sự kiện", được bao gồm trong rất nhiều thông tin CQRS trên mạng.

Theo như tương thích với REST, tôi tin rằng phương pháp này đã được thực hiện (mặc dù tôi không chắc chắn về khía cạnh này), tôi không thể nhớ nếu nó có trong cuốn sách này http://shop.oreilly.com/product/9780596805838.do (REST in Practice), hoặc trong một bài thuyết trình tôi đã nghe bởi Vaughn Vernon tại buổi nói chuyện được ghi lại này trong QCon 2010: http://www.infoq.com/presentations/RESTful-SOA-DDD.

Ông nói về một cái gì đó thiết kế URI như thế này (tôi không nhớ chính xác)

host/tổ chức < - Phiên bản hiện tại của một tài nguyên host/tổ chức/sự kiện < - danh sách các sự kiện mà có đã xảy ra với đột biến đối tượng vào trạng thái hiện tại của nó

Ví dụ:

host/tổ chức/sự kiện/1 < - điều này sẽ tương ứng với việc tạo ra các thực thể host/tổ chức/sự kiện/2 < - đây sẽ cor ứng phó với trường hợp thứ hai bao giờ chống lại các tổ chức

Ông cũng có thể đã có một cái gì đó cho lịch sử, hoàn chỉnh monent-in-time nhà nước, như:

host/đơn vị/phiên bản/2 < - điều này sẽ là toàn bộ trạng thái của thực thể sau sự kiện 2 ở trên.

Vaughn vừa công bố một cuốn sách, Thiết kế Triển khai Domain-Driven, mà từ các bảng nội dung có vẻ như nó bao gồm REST và kiến ​​trúc hướng sự kiện: http://www.amazon.com/gp/product/0321834577

Answer 3

Tôi là tác giả của http://firehose.io/, một khuôn khổ thời gian thực dựa trên tiền đề rằng Streaming RESTful API có thể và nên tồn tại. Từ trang web của dự án:

Firehose là một cách xâm lấn tối thiểu của việc xây dựng các ứng dụng web thời gian thực mà không cần giao thức phức tạp hoặc viết lại ứng dụng của bạn từ đầu. Máy chủ/máy chủ phụ đơn giản giữ các mô hình Javascript phía máy khách trong đồng bộ hóa với mã máy chủ thông qua WebSockets hoặc bỏ phiếu dài HTTP. Nó hoàn toàn bao gồm các mẫu thiết kế RESTful, có nghĩa là bạn sẽ kết thúc với một API tốt đẹp sau khi bạn tạo ứng dụng của mình.

Tôi hy vọng rằng khuôn khổ này ngăn Internet trở lại thời kỳ tối tăm RPC, nhưng chúng ta sẽ thấy điều gì xảy ra. Chúng tôi sử dụng Firehose.io trong sản xuất tại Poll Everywhere để đẩy hàng triệu thư mỗi ngày cho mọi người trên tất cả các loại thiết bị khác nhau. Nó hoạt động.