Это может быть очень общий вопрос, но учитывая тот факт, что REST ориентирован на доступ к именованным ресурсам через один согласованный интерфейс; поддерживает ли он буферы протоколов?Поддерживает ли REST буферы протоколов
У меня возникает соблазн ответить как «да», так и «нет».
REST - это архитектурный стиль, основанный на протоколе HTTP. Он использует, например, HTTP-глаголы. Это заметная разница, например, SOAP, которая намеренно отделена от базового транспорта (HTTP ...)
ОТДЫХ - это представление передачи состояния государства. (Иногда пишется «ReST».) Он полагается на протокол связи без состояния, клиент-сервер, кэшируемый - и практически во всех случаях используется протокол HTTP . REST - это стиль архитектуры для проектирования сетевых приложений .
Источник: rest.elkstein.org/2008/02/what-is-rest.html
При этом, когда дело доходит до определения архитектуры RESTlike, где вы публикуете ресурсы и получаете ресурсы, тогда вы можете определенно использовать любой механизм транспорта и сериализации, который вы желаете. Таким образом, вы можете использовать Proto Buffers или Thrift. Назовите это прагматичный REST, если вы будете
Стоит понять, почему REST пришел, чтобы быть в первую очередь. Еще раз, было понятие интеграции EAI - корпоративного приложения. Это было тяжело, неуклюже, жестко и технологично. Он использовал такие вещи, как CORBA (Java) или COM и DCOM (.NET). Это было тяжело.
Тогда люди подумали: давайте придумаем совместимый стандарт. Так появилась SOA (сервис-ориентированная архитектура) и SOAP (SOAP означал простой протокол доступа к объектам в какой-то момент, но также имел другое значение). SOAP был отличным, потому что он был стандартом, позволяющим взаимодействовать между разными машинами и языками. Таким образом, вы можете отправить SOAP-сообщение из программы Java в .Net-программу. SOAP будет использовать XML как формат сериализации и почти всегда HTTP как транспорт, хотя и не обязательно. У SOAP было понятие транспортных привязок, позволяющее использовать разные транспорты.
SOAP поставляется с длинным списком стандартов, известных как WS- * (например, WS-Security, WS-ReliableMessaging, WS-Eventing ...). В конце концов, это стало слишком много, и люди вместо этого назвали его WS-DeathStar.
REST и JSON возник из-за этого. REST заявил, что мы должны использовать то, что HTTP дал нам, вместо того, чтобы игнорировать его, как SOAP (SOAP придумал SOAPACTION). В то же время угловые скобки (<) выпадали из моды, а фигурные скобки были горячим новым предметом (}). JSON начал заменять XML.
Некоторые из причин успеха REST и JSON над XML являются:
Протобуфы - это всего лишь кодировка, а не транспорт. Protobuf и HTTP никак не конфликтуют - вы можете использовать Protobuf для кодирования объектов, переносимых через HTTP. Ваш «Почему нет?» что вы можете вводить в заблуждение Protobuf для системы RPC, такой как GRPC. –
Да, вы можете абсолютно сочетать Protobuf и REST.
Protbuf указывает способ кодирования данных. REST указывает способ взаимодействия с ресурсами, но не требует какой-либо конкретной кодировки для ресурсов. Если вы создаете API-интерфейс RESTful HTTP и используете Protobuf для кодирования тел-сущностей (технический термин для части полезной нагрузки HTTP-запроса или ответа), вы используете как REST, так и Protobuf.
PB - это, в конечном счете, просто формат данных. Что касается REST, представления ресурсов могут быть отправлены в любом формате данных, согласованном между сервером клиента. В «RESTful equation» нет ничего, что говорит, что один формат данных более RESTful, чем другой формат данных. –
Возможный дубликат [Отправка буферов протокола через REST] (http://stackoverflow.com/questions/3187270/sending-protocol-buffers-via-rest) –