Czy korzystasz z Rejestrujących wysyłane przez serwer HTML5 (SSE)?

Question

Nie jestem w stanie zrozumieć, czy zdarzenia wysłane przez serwer HTML5 rzeczywiście pasują do architektury ReST. Rozumiem, że NIE wszystkie aspekty HTML5/HTTP muszą pasować do architektury ReST. Ale chciałbym się dowiedzieć od ekspertów, która połowa HTTP jest SSE w (Reful połowa lub druga połowa!).

Jednym z poglądów może być fakt, że jest to RESTful, ponieważ istnieje "początkowe" żądanie HTTP GET od klienta do serwera, a pozostałe mogą być postrzegane jako odpowiedzi o treści częściowej tylko o innej treści (" text/event-stream ")

Zapytanie wysłane bez pojęcia, ile odpowiedzi przyjdzie jako odpowiedź (zdarzenia)? Czy to jest ReSTful?

Motywacja do pytania: Rozwijamy stronę serwerową aplikacji i chcemy wspierać zarówno klientów ReST (ogólnie), jak i przeglądarek (w szczególności). Chociaż SSE będą działać dla większości klientów przeglądarek HTML5, nie jesteśmy pewni, czy SSE są odpowiednie do obsługi przez czystego klienta ReST. Stąd pytanie.

Edit1: czytał Roy Fielding stary article, gdzie mówi: Jako takie, życzliwy użytkownik może produkować „Innymi słowy, pojedynczy Wyniki żądanie użytkownika w potencjalnie dużą liczbę obowiązków serwerowych. nieproporcjonalne obciążenie wydawcy lub brokera rozpowszechniającego powiadomienia W Internecie nie mamy luksusu projektowania tylko dla życzliwych użytkowników, a zatem w systemach HTTP takie żądania nazywamy exploitem odmowy usługi ... Właśnie dlatego nie ma standardowego mechanizmu powiadomień w HTTP "

Czy to oznacza, że ​​SSE nie jest PRAWDZIWY?

Edit2: Przeszedłem przez API REST na Twitterze. Chociaż purytanie REST mogą debatować, jeśli ich REST API jest naprawdę/w pełni WYPOCZYNKU, tylko tytuł sekcji Differences between Streaming and REST wydaje się sugerować, że przesyłanie strumieniowe (a nawet SSE) nie może być uważane za POTRZEBNE! Ktoś to twierdzi?

Answer 1

myślę, że to zależy od:

Czy twoi zdarzenia po stronie serwera używać hipermedia oraz hiperłącza do opisania możliwych zmian stanu?

Odpowiedź na to pytanie jest odpowiedzią na pytanie, czy spełniają one funkcję REST w obrębie architektury aplikacji.

Teraz sposób, w jaki te zdarzenia są wysyłane/otrzymywane, może, ale nie musi, odbywać się w trybie REST - wszystko, co czytałem o SSE, sugeruje, że nie. Podejrzewam, że będzie to miało wpływ na kilka zasad, szczególnie na warstwie - choć gdyby pośrednicy wiedzieli o semantyce SSE, prawdopodobnie moglibyście to zanegować.

Myślę, że jest to ortogonalne, ponieważ jest po prostu częścią dyrektywy dotyczącej przetwarzania HTML i JavaScript, którą rozumie przeglądarka (za pomocą działającego JavaScriptu). Nadal powinno być możliwe odłączenie stanu aplikacji po stronie klienta od stanu zasobów po stronie serwera.

Niektóre z porad, jakie widziałem na temat radzenia sobie ze skalowaniem za pomocą SSE, nie pasują do usługi REST - tj. Do wprowadzania niestandardowych nagłówków (modyfikujących protokół).

Jak szanować REST podczas korzystania z SSE?

chciałbym zobaczyć jakiś

<link rel="event" href="http://example.com/user/1" />

wówczas dyrektyw przetwarzania (w tym kod na żądanie, takich jak JavaScript) dowolnego typu zawartości/zasób pracy z opowiadają klientowi, jak subskrybować i wykorzystywać zdarzenia udostępnione z takiego hiperłącza. Oczywiście dane tych zdarzeń powinny same być hipermediami zawierającymi więcej hiperłączy, które kontrolują przepływ programu. (Tutaj wydaje mi się, że wprowadzasz rozróżnienie między REST a nie-REST).

W pewnym momencie przeglądarka może zorientować się w związku z linkiem - podobnie jak stylesheet i zrobić dla Ciebie coś w rodzaju eleganckiego okablowania, więc wystarczy tylko posłuchać wydarzeń w JavaScript.

Chociaż myślę, że Twoja aplikacja może nadal pasować do stylu REST wokół SSE, nie są one REST same w sobie (ponieważ twoje pytanie dotyczyło w szczególności ich użycia, a nie ich implementacji, staram się być jasnym co mówię do).

Nie podoba mi się to, że specyfikacja korzysta z protokołu HTTP, ponieważ eliminuje wiele semantyki i skutecznie tuneluje protokół anemiczny za pomocą innego, względnie bogatego. Jest to podobno zasiłek, ale uderza mnie jako sprzedaż kolacji na obiad.

ReST clients (in general) and Browsers (in particular).

Jak jest Twoja przeglądarka nie klient REST? Przeglądarka to prawdopodobnie najbardziej popularny klient spośród wszystkich. To całe badziewie, do którego wtrącamy się poprzez JavaScript, który sprawia, że ​​przestajemy się trzymać REST. Podejrzewam/obawiam się, że tak długo, jak długo będziemy myśleć o naszych "klientach" REST-API i naszych klientach przeglądarkowych jako zasadniczo różnych, nadal będziemy tkwić w tym obecnym stanie - prawdopodobnie dlatego, że wszyscy ludzie REST szukają hiperłącza, Ludzie RPC nie mają potrzeby, aby istnieć;)

Answer 2

Myślę, że SSE może być używany przez API REST. Zgodnie z Fielding dissertation, mamy pewne ograniczenia architektoniczne, które aplikacja MUSI spełniać, jeśli chcemy ją nazwać REST.

• klient-serwer architektura: ok - klient uruchamia, gdy serwer ma przetwarzania
• bezpaństwowcem: ok - nadal zapisywać stan klienta na kliencie i HTTP jest nadal bezpaństwowcem protokół
• cache: ok - musimy użyć brak nagłówka cache
• jednolity interfejs
  • identyfikacja zasobów: ok - używamy URI
  • manipulacji zasobami poprzez reprezentacje: ok - możemy użyć metody HTTP z tego samego URI
  • własny opisowe komunikaty: ok, częściowo - używamy nagłówka typu treści, możemy dodać RDF do danych, jeśli chcemy, ale nie ma standardu, który opisuje, że dane są kodowane RDF. powinniśmy zdefiniować tekst/strumień zdarzeń + typ MIME RIME lub coś podobnego, jeśli jest to obsługiwane.)
  • Hypermedia jako silnik stanu aplikacji: ok - możemy wysyłać linki w danych
• warstwowy układ: ok - możemy dodać inne warstwy, które mogą przekształcić strumień danych aka. Rury i filtry gdzie pompa jest serwer, czy filtry są te warstwy i zlew jest klient kod
• na żądanie: ok - opcjonalna, nie ma znaczenia

Btw. nie ma takiej zasady, że nie można używać razem różnych technologii. Możesz więc użyć na przykład API REST i stron internetowych razem, jeśli chcesz, ale jeśli część websocket nie spełnia co najmniej samoprzypisującego komunikatu i ograniczeń HATEOAS, wtedy klient będzie trudny do utrzymania. Skalowalność może być kolejnym problemem, ponieważ inne ograniczenia dotyczą właśnie tego.