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

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

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

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

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

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

Означает ли это, что SSE не является ReSTful?

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


http rest html streaming server-sent-events
person 2020    schedule 01.04.2013    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Я думаю, это зависит от следующих обстоятельств:

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

Ответ на этот вопрос - ответ на вопрос, удовлетворяют ли они 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 понятия не имеют, что нужно существовать;)

person Doug Moscrop    schedule 05.06.2013
comment
Спасибо ! Я согласен с вашим мнением относительно HATEOAS. Я действительно ожидаю, что события будут следовать этому ограничению, хотя SSE этого не требует. Мой вопрос больше касается конкретной проблемы A request sent without any idea of how many responses are going to come as response(events) ? Is that ReSTful ? - person 2020; 06.06.2013
comment
Что ж, я думаю, что «ответ» - не совсем правильный термин - если я сделаю запрос на веб-камеру для потоковой передачи в реальном времени, я не могу точно сказать, сколько данных я бы получил обратно в качестве «ответа», верно? Я не думаю, что это особенно относится к REST, поскольку ответ просто должен включать механизм, с помощью которого я могу перейти в какое-то другое состояние (а «назад» - это неявный переход состояния для клиентского приложения). SSE отменяет событие. - person Doug Moscrop; 06.06.2013
comment
Если вас это действительно беспокоит, я бы сказал, что события - это не REST, а остальная архитектура - вы можете сформулировать это так, как переход между состояниями в нашей архитектуре является репрезентативным. а затем вы определили, что такое REST на самом деле - это изменение состояния. Уведомления о событиях не являются частью изменения состояния, потому что простое получение события не должно инициировать изменение состояния в приложении. - person Doug Moscrop; 06.06.2013
comment
Кроме того, часть той статьи была о том, почему HTTP не имеет стандартной модели PubSub. Также возможно, что доктор Филдинг (или «Как я научился перестать беспокоиться и полюбить ОТДЫХ») был неправ - он умный парень, без сомнения, но никто не идеален. Прошло почти полдесятилетия, и я не думаю, что Твиттеру пришлось предпринять действия, которые он предсказывал. Я не понимаю, почему это так важно, потому что интеграция на основе событий должна выиграть от тех же слоев и кеширования, что и обычный HTTP, а альтернативой является то, что ваша инфраструктура должна справляться с частыми запросами. Такая же нагрузка, не так ли? - person Doug Moscrop; 06.06.2013
comment
@Doug: Одно замечание заключается в том, что даже если нагрузка фактически одинакова, ее нелегко (вообще?) Распределить таким же образом. Все клиенты привязаны к одному серверу на неопределенный срок. Проксирование через пограничный сервер может помочь, но у этого сервера все еще могут возникнуть проблемы с масштабированием. В спецификации действительно упоминается, как правильно восстановить соединение, чтобы сервер мог передать соединение другому серверу; Хотя это не кажется тривиальной задачей. Также необходимо учитывать, сколько существует источников событий и как передать событие на все нужные серверы на стороне сервера. - person tne; 02.10.2013

arrow_upward
1
arrow_downward

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

  • архитектура клиент-сервер: нормально - клиент запускается, пока сервер выполняет обработку.
  • без сохранения состояния: хорошо - мы по-прежнему сохраняем состояние клиента на клиенте, а HTTP по-прежнему является протоколом без отслеживания состояния.
  • cache: ok - мы не должны использовать заголовок кеша
  • uniform interface
    • identification of resources: ok - we use URIs
    • манипулирование ресурсами через представления: хорошо - мы можем использовать HTTP-методы с тем же URI
    • Самоописательные сообщения: хорошо, частично - мы используем заголовок типа содержимого, мы можем добавить RDF к данным, если захотим, но нет стандарта, который описывает, что данные закодированы в RDF. мы должны определить MIME-тип text / event-stream + rdf или что-то в этом роде, если это поддерживается.)
    • гипермедиа как движок состояния приложения: хорошо - мы можем отправлять ссылки в данных
  • многоуровневая система: хорошо - мы можем добавить другие слои, которые могут преобразовывать поток данных, также известный как. трубы и фильтры, где насос - это сервер, фильтры - эти слои, а сток - клиент
  • код по запросу: ok - необязательно, не имеет значения

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

person inf3rno    schedule 06.10.2015
comment
Я не согласен. Это ограничения. Например, SSE нарушает ограничение кеширования, потому что вы не можете кэшировать text/event-stream (это бессмысленно, и спецификация запрещает это). У потока SSE нет модели обработки, поэтому невозможно рассуждать о таком потоке самостоятельно, в отличие от того, как можно рассуждать об ответе HTML - в частности, это (отсутствие) унифицированного интерфейса. - person mogsie; 10.11.2015
comment
@mogsie "Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable." Как я уже писал, настоящая проблема связана с информативными сообщениями. В настоящее время он не совместим с REST, но с небольшими изменениями в стандарте SSE может быть. Думаю. - person inf3rno; 10.11.2015