Можно ли использовать приложение HTTP REST API для чата?

Ответ 1

Мы можем использовать REST API для обмена чатами, но IMHO, XMPP - лучшая альтернатива. Давайте рассмотрим, что XMPP может предложить.

XMPP наряду с поддержкой транспорта TCP также предоставляет HTTP (через опрос и привязку) и websocket. Прочитайте XMPP через HTTP и WebSocket транспорты

Было бы интересно понять плюсы и минусы каждого транспорта с точки зрения XMPP.

XMPP может использовать HTTP двумя способами: опрос [18] и привязка.

XMPP через HTTP-опрос

Опрос метод, теперь устаревший, по существу означает сообщения, хранящиеся на серверная база данных регулярно выбирается (и публикуется) посредством XMPP-клиент посредством HTTP-запросов "GET" и "POST".

XMPP через HTTP-привязку (BOSH)

Метод привязки считается более эффективным, чем обычные HTTP-запросы GET и POST в методе опроса, поскольку он снижает латентность и потребление полосы пропускания по сравнению с другими методами опроса HTTP

Однако это также создает недостаток, что сокеты остаются открытыми в течение длительного времени, ожидая следующего запроса клиента

Метод привязки, реализованный с использованием двунаправленных потоков через синхронный HTTP (BOSH), [19] позволяет серверам отправлять сообщения клиентам, как только они посланы. Эта push-модель уведомления более эффективна, чем опроса, где многие опросы не возвращают новых данных.

Было бы хорошо, если мы поймем, как работает метод BOSH.

Техника, используемая BOSH, которая иногда называется "HTTP long опрос", снижает латентность и потребление полосы пропускания по сравнению с другими HTTP-протоколами методы опроса. Когда клиент отправляет запрос, соединение менеджер не сразу отправляет ответ; вместо этого он удерживает запрос открывается до тех пор, пока у него не будет данных для фактической отправки клиенту (или истек срок действия бездействия). Затем клиент немедленно отправляет новый запрос диспетчеру соединений, продолжая длинный цикл опроса.

Если диспетчер соединений не имеет данных для отправки клиенту после некоторого согласованного промежутка времени [12], он отправляет ответ с пустой. Это служит аналогичной цели для сторонних владельцев или XMPP Ping (XEP-0199) [13]; это помогает поддерживать активное соединение сокета который предотвращает некоторые посредники (брандмауэры, прокси и т.д.) из тихо отбрасывая его и помогает обнаруживать перерывы в разумных количество времени.

XMPP через привязку WebSocket

XMPP поддерживает привязку WebSocket, которая является более эффективной транспортной

Возможно, более эффективный транспорт для обмена сообщениями в режиме реального времени WebSocket, веб-технология, обеспечивающая двунаправленный, полнодуплексный каналов связи по одному TCP-соединению. XMPP за Связывание WebSocket определено в предложенном IETF стандарте RFC 7395.

Говоря об кривой обучения, да, у вас может возникнуть соблазн использовать REST API, но теперь есть несколько ресурсов, чтобы узнать о Android и XMPP и программное обеспечение сервера XMPP, которое вы можете использовать для запуска собственной службы XMPP либо через Интернет, либо в локальной сети. Стоит потратить эти усилия, прежде чем вы решите свою архитектуру.

Ответ 2

Не рекомендуется использовать HTTP Rest API для чата или аналогичных приложений реального времени.

Некоторые сведения..

Клиентские требования чата

• Список друзей выберите

• Проверьте онлайн/друзей в автономном режиме

• Получить сообщения чата в режиме реального времени и отправлять сообщения.
• Получение уведомлений о доставке/чтении и т.д.

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

Для остальных точек потребуется постоянная проверка данных с сервера или другой части в случае клиента p2p. Это позволит вам создать длинные или короткие запросы на опрос гостей, чтобы следить за новыми данными или другими обновлениями.

Проблема с клиентом HTTP Rest

Это не поддерживает связь типа "живое", из-за чего вам придется создавать несколько http-соединений, которые будут иметь слишком много накладных расходов, что они станут слишком отсталыми. Поскольку пересоединение является очень дорогостоящим в HTTP-вызовах.

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

Другое решение В случае, если вы застряли с некоторыми устаревшими системами, в случае которых вы обязаны использовать оставшийся режим api.

Попробуйте CometD, это гибридный подход к websockets и ajax-опросу, который даст вам возможность общаться в режиме реального времени, а также работать с клиентами, которые не поддерживают веб-сайты, отказываясь от механизмов опроса ajax. Также он использует различные оптимизации, чтобы избежать повторного подключения снова и снова.

Ссылка CometD

Вы также можете попробовать Socket.io, который также является удивительной технологией для решения таких случаев использования.

Ответ 3

Я думаю, что подход REST может работать в чате. Предположим, что

• http://chat.example.com/conversations ссылается на все разговоры
  • GET выбирает список
  • POST создает новый
• http://chat.example.com/conversations/123 ссылки на беседу # 123
  • GET извлекает сообщения в этом разговоре
  • POST добавляет сообщение в цепочку

Если я правильно понимаю, ваш вопрос касается последней точки.

Как только клиент отправил сообщение outboud в http://chat.example.com/conversations/123, он закроет http-соединение.

Недостатком является то, что получение входящих сообщений просто невозможно в этом случае. Вам понадобится другой канал (возможно, просто Google cloud messaging).

Напротив, WebSockets и XMPP поддерживают соединение, поэтому они могут получать сообщения без задержки. Но недостатком их обоих является то, что это представляет собой стоимость на сервере с точки зрения масштабируемости; и затраты на клиента с точки зрения использования аккумулятора.

На сервере:

• сокеты - относительный скудный ресурс
• Невозможно переместить клиентов для балансировки нагрузки, если у них есть открытое соединение (но можете ли вы действительно перемещать клиентов в любом случае? это зависит от ответственности уровней)

На клиенте:

• поддержание сетевого соединения чрезвычайно дорого. 1 с сети ≈ 5 минут сна.
• XMPP librairies не обязательно работают очень хорошо на Android. И я понятия не имею о поддержке WebSockets на Android.

Ответ 4

Краткий ответ №

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

Ваш + HTTP endpoint is easy to scale horizontally on server side pro является профи в контексте, когда HTTP используется как стиль запроса и ответа и когда он считается безстоящим. Он становится несколько спорным (хотя и не полностью), когда вам по существу нужно поддерживать связь.

HTTP предлагает еще одно преимущество, о котором вы не упомянули здесь.

• HTTP легко справляется с корпоративными прокси-серверами, когда другие порты могут быть заблокированы.

Здесь WebSockets или XMPP через HTTP будут иметь лучшую скорость успеха, как упоминалось другими.

Ответ 5

Это зависит. Вы считаете, что ваше приложение является "чатом в чате"? Вам нужен индикатор присутствия или индикатор ввода? Такие функции требуют постоянного подключения. Но есть еще один набор чат-приложений, которые вы бы описали как "обмен сообщениями в приложении". Эти приложения хранят разговоры и списки разговоров на каком-то бэкэнде; просто установите приложение на другое устройство и войдите в систему, и вы увидите свои разговоры по этому типу приложений. В этих приложениях нет индикатора присутствия или ощущения оживленности.

Хотя я не выполнил какое-либо приложения с XMPP, он выглядит, насколько настойчивость сообщения, наиболее настойчивость вы найдете с XMPP (из коробки) является упорствовать-до-сервисы, подобно SMS. Возможно, вы могли бы создать механизм хранения/восстановления для XMPP, захватив строфы во время их прохождения и хранения в своей собственной БД. Но если вам не нужен полный "чат", использование базы данных, HTTP-сервис и push-уведомления (для уведомления об обновленных потоках), похоже, являются сплошным путем для приложений с функциями обмена сообщениями, которые я намерен реализовать в iOS и Android-приложение прямо сейчас.

Сообщите мне, если вы нашли хорошие схемы open-source/API для этого.