Использует HTML5 Server-sent-events (SSE) ReSTful?

Я не могу понять, действительно ли HTML5s-сервер-события действительно вписываются в архитектуру ReST. Я понимаю, что НЕ все аспекты HTML5/HTTP должны соответствовать архитектуре ReST. Но мне хотелось бы узнать от экспертов, какая половина HTTP - SSE (половина или другая половина!).

Одно из представлений может состоять в том, что оно является ReSTful, потому что есть "начальный" HTTP-запрос GET от клиента на сервер, а остальные могут рассматриваться только как частичный контент только для другого типа контента ( "текст" /событие-поток ")

Запрос, отправленный без какого-либо представления о том, сколько ответов будет отправлено в качестве ответа (событий)? Это ReSTful?

Мотивация для вопроса: мы разрабатываем серверную часть приложения, и мы хотим поддерживать как клиентов ReST (в общем), так и браузеры (в частности). Хотя SSE будут работать для большинства браузеров HTML5, мы не уверены, подходят ли SSE для поддержки чистым клиентом ReST. Отсюда вопрос.

Edit1: Читал статью Роя Филдинга , где он говорит: Другими словами, один запрос пользователя приводит к потенциально большому количеству обязательств сервера. Таким образом, доброжелательный пользователь может создавать непропорциональную нагрузку на издателя или брокера, который распространяет уведомления., у нас нет роскоши проектирования только для доброжелательных пользователей, и, следовательно, в HTTP-системах мы называем такие запросы эксплойтом отказа в обслуживании.... Именно поэтому нет стандартного механизма для уведомлений в HTTP "

Это означает, что SSE не перегружен?

Edit2: Прошел через REST API Twitter. В то время как REST puritans могут обсуждать, действительно ли их REST API действительно/полностью REST, просто название раздела Различия между Streaming и REST, похоже, показывают, что Streaming (и даже SSE) не может считаться перегруженным!? Кто-нибудь утверждает, что?

Ответ 1

Я думаю, это зависит:

Слушайте ли серверные события гипермедиа и гиперссылки для описания возможных изменений состояния?

Ответ на этот вопрос - это ответ на то, удовлетворяет ли REST в архитектуре вашего приложения или нет.

Теперь способ, которым эти события отправляются/получаются, может или не может соответствовать REST - все, что я прочитал о SSE, говорит о том, что они этого не делают. Я подозреваю, что это повлияет на несколько принципов, особенно на слоирование - хотя, если бы посредники знали о семантике SSE, вы, вероятно, могли бы отрицать это.

Я думаю, что это ортогонально, поскольку это просто часть директивы обработки для HTML и JavaScript, которую понимает браузер (через JavaScript, который он запускает). Вы все равно должны иметь возможность отключить состояние приложения на стороне клиента из состояния ресурса на стороне сервера.

Некоторые из рекомендаций, которые я видел о том, как справляться с масштабированием с помощью SSE, не подходят для REST - то есть, ввод пользовательских заголовков (изменение протокола).

Как вы относитесь к REST при использовании SSE?

Я хотел бы видеть какой-то

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

Затем директивы обработки (включая код по требованию, такой как JavaScript) любого типа контента/ресурса, с которым вы работаете, сообщают клиенту, как подписываться и использовать события, доступные из такой гиперссылки. Очевидно, что данные этих событий должны быть гипермедиа, содержащие больше гиперссылок, управляющих потоком программы. (Здесь я считаю, что вы делаете различие между REST и not-REST).

В какой-то момент браузер узнает об этой связи - так же, как и stylesheet, и сделайте некоторые из этих причудливых подключений для вас, поэтому все, что вы делаете, это просто прослушивать события в JavaScript.

В то время как я действительно думаю, что ваше приложение может по-прежнему соответствовать стилю REST вокруг SSE, они сами не являются REST (так как ваш вопрос касался их использования, а не их реализации, я пытаюсь понять, о чем говорю).

Мне не нравится, что спецификация использует HTTP, потому что она устраняет много семантики и эффективно туннелирует анемичный протокол через иначе относительно богатый. Это, предположительно, преимущество, но поражает меня, как продавать обед, чтобы заплатить за обед.

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

Как ваш браузер не является клиентом REST? Браузер, возможно, самый лучший клиент REST. Все это дерьмо, которое мы используем для них с помощью JavaScript, который затем прекращает придерживаться REST. Я подозреваю/опасаюсь, что пока мы продолжаем думать о наших клиентах REST-API и наших клиентах с браузерами как принципиально другие, мы все равно будем застрять в этом текущем состоянии - по-видимому, потому, что все люди REST ищут гиперссылку, Люди RPC не имеют идеи, чтобы существовать;)

Ответ 2

Я думаю, что SSE может использоваться API REST. Согласно Филдинг-диссертации, у нас есть некоторые архитектурные ограничения, к которым приложение ДОЛЖНО встретиться, если мы хотим называть его REST.

архитектура клиент-сервер: ok - клиент запускает, пока сервер выполняет обработку
stateless: ok - мы все еще сохраняем состояние клиента на клиенте, а HTTP по-прежнему является протоколом без учета состояния
cache: ok - нам не нужно использовать заголовок кэша
единый интерфейс
- идентификация ресурсов: ok - мы используем URI
- манипулирование ресурсами через представления: ok - мы можем использовать HTTP-методы с тем же URI
- самоописательные сообщения: ok, частично - мы используем заголовок типа контента, мы можем добавить RDF к данным, если хотим, но нет стандарта, который описывает, что данные кодируются RDF. мы должны определить тип текста/события-потока + rdf MIME или что-то подобное, если это поддерживается.)
- гипермедиа как механизм состояния приложения: ok - мы можем отправлять ссылки в данные
многоуровневая система: ok - мы можем добавить другие слои, которые могут преобразовывать поток данных. трубы и фильтры, где насос является сервером, фильтры являются этими слоями, а раковина - клиентом.
код по запросу: ok - необязательно, не имеет значения

Btw. нет такого правила, что вы не можете использовать разные технологии вместе. Таким образом, вы можете использовать, например, REST API и websockets, если хотите, но если часть websockets не встречается, по крайней мере, с самоописательным сообщением и ограничениями HATEOAS, то клиент будет трудно поддерживать. Масштабируемость может быть другой проблемой, поскольку другие ограничения касаются этого.