Среды RPC, такие как Apache Thrift или GRPC, или любая другая среда RPC RESTful? - PullRequest
Новая
       46

Среды RPC, такие как Apache Thrift или GRPC, или любая другая среда RPC RESTful?

0 голосов
/ 10 июня 2018

Просто чтобы уточнить, что я имею в виду под RESTful , оно должно удовлетворять следующим ограничениям, взятым из здесь :

  • Uniform Interface

  • Без состояния

  • Кэшируется

  • Клиент-сервер

  • Многоуровневая система

  • Код по требованию

Из моего исследования я считаю, что они не RESTful, в первую очередь потому, что:

  1. Они не используют HTTP-глаголы.

  2. Они не используют HTTP-коды ответов.

  3. Они не следуют принципам REST-связности, основанным на HATEOAS .

См. этот ресурс для получения дополнительной информации о данных, на которых основаны вышеприведенные выводы.

Некоторые ресурсы, такие как , эти , похоже,предположить, что эти платформы могут использоваться / реализовываться как RESTful.

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

Ответы [ 2 ]

0 голосов
/ 12 июня 2018

REST по определению не RPC, потому что наиболее существенным отличием REST является то, что он ориентирован на ресурсы, а RPC (как правило) - нет.

Кроме того, следует воздерживаться от попыток решить проблемы, которые требуют RPC, путем изобретения решения "RPC over REST" - программисты SE полны таких вопросов.

На самом деле такой подход был бы перевернутым: можно реализовать систему, основанную на REST, с помощью RPC, но вся идея, почему кто-то захочет использовать REST, заключается вАбсолютно другая плоскость абстракции.

Так что я бы сказал, что вопрос (в некотором роде) является ошибкой категории.

0 голосов
/ 10 июня 2018

Являются ли фреймворки RPC, такие как Apache Thrift или GRPC, или любая другая фреймворк RPC RESTful?

Взяты отдельно: нет.

Окончательная ссылка на REST: Архитектурные стили и проектирование сетевых программных архитектур .Рой Филдинг описывает архитектурные ограничения, которые были разработаны при работе над веб-стандартами ( RFC 1945 , RFC 2068 , RFC 2616 , позже RFC 7230 ).

REST предназначен для долговечных сетевых приложений, охватывающих несколько организаций ( Fielding, 2008 )

"The«Всемирная паутина» - это пример приложения, созданного с использованием архитектурного стиля REST.

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

Некоторые ресурсы, подобные этим, предлагают использовать / реализовывать эти инфраструктуры как RESTful.

Люди, которые понимают, что REST означает HTTP + JSON, придут к выводам, которые несовместимы с веб-архитектурой и тезисом Филдинга.

Вкратце - HTML делает лот тяжелой работы в создании успешного архитектурного стиля сети.JSON, напротив, не включает семантику «ссылки» или «формы», которая может использоваться для сообщения клиенту, какие переходы возможны.Вам нужна другая семантика поверх JSON, чтобы сервер мог сообщить клиенту, какие переходы приложений возможны; Web Linking или гипермедиа-ориентированный диалект JSON.

Насколько можно судить, вы могли бы использовать Thrift для создания приложения, которое удовлетворяет архитектурным ограничениям REST.Но я предполагаю, что это не будет особенно приятным опытом: Thrift был разработан, потому что Facebook нужна была система со свойствами, которые не удовлетворяли бы веб-архитектуре.

REST отлично подходит для Интернета.Однако стек, состоящий из REST, HTTP и JSON, не оптимален для высокой производительности, необходимой для внутренней передачи данных.Действительно, сериализация и десериализация этих протоколов и форматов может нанести ущерб общей скорости.- Leo Schoukroun

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

Это похоже насделанный нами компромисс между HTML и JSON - JSON не является полезным гипермедиа представлением;но он вполне подходит для потребления кодом по требованию, который был загружен нашим представлением hypermedia .

Лошади для курсов.

...