Хорошо ли, чтобы пользовательский протокол отдыха был двоичным, а не текстовым, как Http?

Question

Вы когда-нибудь видели вескую причину для создания собственного двоичного протокола покоя вместо использования базовой реализации http покоя?

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

Так что здесь я пытаюсь найти лучший протокол для обработки этой инфраструктуры SOA. Мне нравится природа соединения REST без запросов состояния и ответа и URI для определения ресурсов, но мне не нравится текстовая природа HTTP.

Вот мои аргументы за неприязнь к HTTP, поправьте меня, если я ошибаюсь:

• Сначала доказательство, синтаксический анализ текста менее эффективен, чем анализ двоичного. Я бы предпочел двоичный заголовок фиксированной длины, содержащий длину содержимого и двоичное содержимое.

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

Чтобы добавить немного больше контекста, моей SOA-инфраструктуре не нужно быть доступным не потребителю .Net, поэтому у меня нет ограничений на использование двоичного форматера .Net или другого пользовательского двоичного форматера.

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

Спасибо.

Answer 1

REST - это архитектурный стиль для построения веб-сервисов. Рой Филдинг сформулировал это, основываясь на своем опыте разработки HTTP, но он превосходит HTTP. Например, вы можете развернуть службу RESTful через обычный почтовый обмен.

REST-представления ваших ресурсов могут быть чем угодно, хотя Рой действительно подчеркивает, что люди должны стараться использовать очень тщательно разработанные стандартные представления. Там нет ничего плохого с двоичным. На самом деле представления изображений, такие как JPEG и PNG, являются двоичными. Google Protocol Buffers также позволяет создавать компактные двоичные представления структурированных данных.

Таким образом, короткий ответ заключается в том, что вы, безусловно, можете быть RESTful и использовать двоичные представления и домашнюю двоичную замену HTTP.

Я бы очень рекомендовал использовать HTTP для эффективности. Если вы используете свой собственный протокол, вы потеряете все рычаги, предоставляемые замечательной инфраструктурой кэширования HTTP, которая стоит между вашим сервером и его клиентами. Полная загрузка клиента падает прямо на ваш сервер, а не распределяется по промежуточным кешам.

10/4/2010: В наших API REST на основе HTTP мы теперь поддерживаем Java Serialized Object и двоичные представления Kryo в дополнение к XML, JSON и XHTML. Библиотека сериализации Kryo работает значительно лучше других, не требуя какого-либо специального протокола. Другой альтернативой для сокращения пропускной способности является использование сжатия HTTP вместе с текстовым представлением.

Answer 2

Данные ваших пакетов могут быть любыми; будь то XML, обычный текст, JSON или просто двоичный формат. Я не вижу причин навязывать какой-либо конкретный из них самому себе (используйте все, что вам подходит).

Хотя, говоря «двоичный формат», большинство людей слышит фиксированный формат длин полей и другие действительно раздражающие вещи. Как правило, если вы не в отчаянии с точки зрения передачи данных, я не вижу причин идти по этому пути [хотя вы можете выполнить двоичную сериализацию объектов .net, чтобы их можно было повторно создать [или посмотреть библиотека буферов протокола для .net]].

Резюме: Кажется, все в порядке. Все, что плывет на твоей лодке.

Answer 3

Я хочу полной гибкости и контроля

Исходя из этого утверждения, я бы предложил один из двух вариантов. Либо прямые сокеты TCP / IP, либо WCF. Эти параметры дают вам наибольшую гибкость. WCF - отличное решение, если вы хотите быть независимым от транспорта и хотите начать с чистого состояния в том, что касается протокола приложения.

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

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

Answer 4

Вы когда-нибудь видели вескую причину для создания собственного двоичного протокола покоя вместо использования базовой реализации http покоя?

Я не уверен, что понимаю ваши условия. Представление REST может быть полностью двоичным и все же передаваться по чистому HTTP. Нет необходимости изобретать новый протокол только для передачи двоичных данных. Просто сведите ваши требования к хорошо документированному типу носителя (который вы можете изобретать).

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

Независимо от того, используете ли вы прямой двоичный код, Base64, смешанный с текстом, или только текстовый, не забывайте гипертекстовое ограничение , если вы планируете вызывать то, что делаете, "REST".

Так есть ли у меня какой-то смысл хотеть собственный двоичный протокол отдыха?

Если вы имеете в виду, что вы хотите создать пользовательский носитель с гипертекстовым типом, предназначенный только для двоичных файлов, - это вполне разумно.

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