Как объединить веб-сокеты и http для создания REST API, который поддерживает актуальность данных?

Идея B для меня лучшая, потому что клиент специально подписывается на изменения в ресурсе и получает добавочные обновления с этого момента.

Нужно ли вообще использовать REST или ws достаточно для всех данных?

Пожалуйста, проверьте: WebSocket/REST: клиентские подключения?

Я не знаю Java, но я работал с Ruby и C над этими проектами...

Как ни странно, я думаю, что самым простым решением является использование JSON, где REST API просто добавляет данные method (то есть method: "POST") в JSON и перенаправляет запрос тому же обработчику, который использует Websocket.

Ответ базового API (ответ от API, обрабатывающего запросы JSON) может быть переведен в любой нужный вам формат, например, в HTML-рендеринг... хотя я бы рассмотрел возможность простого возврата JSON для большинства случаев использования.

Это помогает инкапсулировать код и сохранить его СУХИМ при доступе к одному и тому же API с использованием как REST, так и веб-сокетов.

Как вы можете догадаться, такой дизайн упрощает тестирование, поскольку базовый API, обрабатывающий JSON, можно тестировать локально без необходимости эмуляции сервера.

Удачи!

P.S. (Pub/Sub)

Что касается Pub/Sub, я считаю, что лучше всего иметь «ловушку» для любых вызовов API обновления (обратный вызов) и отдельный модуль Pub/Sub, который обрабатывает эти вещи.

Я также считаю, что более экономично записывать все данные в службу Pub/Sub (вариант B), а не только ссылочный номер (вариант C) или сообщение «доступно обновление» (варианты A и D).

В общем, я также считаю, что отправка всего списка пользователей неэффективна для больших систем. Если у вас нет 10-15 пользователей, вызов базы данных может оказаться неудачным. Рассмотрим администратора Amazon, запрашивающего список всех пользователей... Бррр....

Вместо этого я бы рассмотрел возможность разделения на страницы, скажем, 10-50 пользователей на странице. Эти таблицы могут быть заполнены с помощью нескольких запросов (Websocket/REST, не имеет значения) и легко обновлены с помощью живых сообщений Pub/Sub или перезагружены, если соединение было потеряно и восстановлено.

ИЗМЕНИТЬ (REST и веб-сокеты)

Что касается REST и веб-сокетов... Я считаю, что вопрос о необходимости в основном является подмножеством вопроса "кто клиент?"...

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

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

По той же причине (как и по другим причинам) веб-сокеты обычно имеют преимущество в отношении производительности... насколько большое преимущество над REST зависит от транспортного уровня REST (HTTP/1.1, HTTP/2 и т. д.).

Обычно этими вещами можно пренебречь, когда приходит время предлагать публичную точку доступа к API, и я считаю, что реализация обоих — это, вероятно, путь на данный момент.

Другой вариант — использовать Firebase Cloud Messaging:

Используя FCM, вы можете уведомить клиентское приложение о том, что новая электронная почта или другие данные доступны для синхронизации.

Как это работает?

Реализация FCM включает два основных компонента для отправки и получения:

• Надежная среда, такая как облачные функции для Firebase или сервер приложений, на котором можно создавать, настраивать и отправлять сообщения.
• Клиентское приложение iOS, Android или веб-приложение (JavaScript), которое получает сообщения.

Клиент регистрирует свой ключ Firebase на сервере. Когда обновления доступны, сервер отправляет push-уведомление на ключ Firebase, связанный с клиентом. Клиент может получать данные в структуре уведомления или синхронизировать их с сервером после получения уведомления.

Как правило, вы можете взглянуть на современные веб-фреймворки «реального времени», такие как MeteorJS, которые решают именно эту проблему.

Meteor в конкретном случае работает более или менее так же, как ваш пример D, с подписками на определенные данные и дельты, отправляемые после изменений только затронутым клиентам. Используемый ими протокол называется DDP, который дополнительно отправляет дельты не в виде HTML, подверженного накладным расходам, а в виде необработанных данных.

Если веб-сокеты недоступны, запасные варианты, такие как длинный опрос или события, отправленные сервером можно использовать.

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

Сторона сервера:

socket.on('getUsers', () => {
    // Get users from db or data model (save as user_list).
    socket.emit('users', user_list );
})
socket.on('createUser', (user_info) => {
    // Create user in db or data model (save created user as user_data).
    io.sockets.emit('newUser', user_data);
})

Сторона клиента:

socket.on('newUser', () => {
    // Get users from db or data model (save as user_list).
    socket.emit('getUsers');
})
socket.on('users', (users) => {       
    // Do something with users
})

Это использует socket.io для node. Я не уверен, каков ваш точный сценарий, но это сработает для этого случая. Если вам нужно включить конечные точки REST, это тоже будет хорошо.

Со всей отличной информацией, которую все великие люди добавили до меня.

Я обнаружил, что в конечном итоге нет правильного или неправильного, все просто сводится к тому, что соответствует вашим потребностям:

давайте возьмем CRUD в этом сценарии:

Подход только WS:

Create/Read/Update/Deleted information goes all through the websocket.    
--> e.g If you have critical performance considerations ,that is not 
acceptable that the web client will do successive REST request to fetch 
information,or if you know that you want the whole data to be seen in 
the client no matter what was the event ,  so just send the CRUD events 
AND DATA inside the websocket.

WS ДЛЯ ОТПРАВКИ ИНФОРМАЦИИ О СОБЫТИИ + REST ДЛЯ ПОТРЕБЛЕНИЯ САМИХ ДАННЫХ

Create/Read/Update/Deleted , Event information is sent in the Websocket,
giving the web client information that is necessary to send the proper 
REST request to fetch exactly the thing the CRUD that happend in server.

например WS отправляет UsersListChangedEvent {"ListChangedTrigger: "ItemModified", "IdOfItem":"XXXX#3232", "UserExtrainformation":" Достаточно информации, чтобы позволить клиенту решить, имеет ли он значение для получения измененных данных"}

Я обнаружил, что использование WS [только для использования данных событий] и REST [для использования данных] лучше, потому что:

[1] Разделение между моделями чтения и записи. Представьте, что вы хотите добавить некоторую информацию о времени выполнения, когда ваши данные извлекаются при их чтении из REST, что теперь достигается, потому что вы не смешиваете модели записи и чтения, как в 1.

[2] Допустим, другая платформа, не обязательно веб-клиент, будет использовать эти данные. поэтому вы просто меняете триггер события с WS на новый способ и используете REST для потребления данных.

[3] Клиенту не нужно писать 2 способа чтения новых/измененных данных. обычно также есть код, который считывает данные при загрузке страницы, а не
через веб-сокет, этот код теперь можно использовать дважды, один раз при загрузке страницы и второй раз, когда WS инициировал определенное событие.

[4] Возможно, клиент не хочет получать нового пользователя, потому что в настоящее время он показывает только представление старых данных [например, users] , а новые изменения данных не в его интересах извлекать ?

Я лично использовал Idea B в производстве и очень доволен результатами. Мы используем http://www.axonframework.org/, поэтому каждое изменение или создание объекта публикуется. как событие во всем приложении. Затем эти события используются для обновления нескольких моделей чтения, которые в основном представляют собой простые таблицы Mysql, поддерживающие один или несколько запросов. Я добавил несколько перехватчиков в обработчики событий, которые обновляют эти модели чтения, чтобы они публиковали события, которые они только что обработали, после фиксации данных в БД.

Публикация событий осуществляется через STOMP через веб-сокеты. Это делается очень просто, если вы используете поддержку Spring Web Socket (https://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html). Вот как я это написал:

@Override
protected void dispatch(Object serializedEvent, String topic, Class eventClass) {
    Map<String, Object> headers = new HashMap<>();
    headers.put("eventType", eventClass.getName());
    messagingTemplate.convertAndSend("/topic" + topic, serializedEvent, headers);
}

Я написал небольшой конфигуратор, который использует API фабрики компонентов Springs, чтобы я мог аннотировать свои обработчики событий Axon следующим образом:

@PublishToTopics({
    @PublishToTopic(value = "/salary-table/{agreementId}/{salaryTableId}", eventClass = SalaryTableChanged.class),
    @PublishToTopic(
            value = "/salary-table-replacement/{agreementId}/{activatedTable}/{deactivatedTable}",
            eventClass = ActiveSalaryTableReplaced.class
    )
})

Конечно, это только один из способов сделать это. Подключение на стороне клиента может выглядеть примерно так:

var connectedClient = $.Deferred();

function initialize() {
    var basePath = ApplicationContext.cataDirectBaseUrl().replace(/^https/, 'wss');
    var accessToken = ApplicationContext.accessToken();
    var socket = new WebSocket(basePath + '/wss/query-events?access_token=' + accessToken);
    var stompClient = Stomp.over(socket);

    stompClient.connect({}, function () {
        connectedClient.resolve(stompClient);
    });
}


this.subscribe = function (topic, callBack) {
    connectedClient.then(function (stompClient) {
        stompClient.subscribe('/topic' + topic, function (frame) {
            callBack(frame.headers.eventType, JSON.parse(frame.body));
        });
    });
};

initialize();

я предпочитаю A, он позволяет клиенту гибко обновлять существующие данные или нет.

также с этим методом реализация и контроль доступа становятся намного проще.

например, вы можете просто транслировать событие userUpdated всем пользователям, это экономит список клиентов для выполнения конкретных трансляций, а Access Controls and Authentications, применяемый для вашего REST-маршрута, не нужно менять на повторное применение, потому что клиент снова сделает запрос GET.

Многое зависит от того, какое приложение вы делаете.