REST для обмена сообщениями с низкой задержкой.

Question

почему вы не видите больше людей, использующих архитектуру REST для системы клиент-сервер. Вы видите людей, использующих сокеты, или TIBCO RV, или EMS, или MQ, но я не видел много основной архитектуры REST

Кто-нибудь знает причину, по которой вы бы не использовали эту архитектуру для связи клиент-сервер для высокой сквозной пут / низкой задержки

Answer 1

REST не подходит для каждой проблемы.

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

С другой стороны, он добавляет слой HTTP. Вы получаете плавную интеграцию прокси, кэширования и т. Д., Но теряете некоторую скорость из-за заголовков HTTP, веб-сервера и т. Д.

Answer 2

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

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

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