В чем разница между RPC и REST?
RPC и REST – два архитектурных стиля проектирования API. API – это механизмы, которые позволяют двум программным компонентам взаимодействовать друг с другом, используя набор определений и протоколов. Разработчики программного обеспечения используют ранее разработанные или сторонние компоненты для выполнения функций, поэтому им не нужно писать все с нуля. RPC API позволяют разработчикам вызывать удаленные функции на внешних серверах, как если бы они были локальными для своего программного обеспечения. Например, вы можете добавить функцию чата в свое приложение, удаленно вызывая функции обмена сообщениями в другом приложении чата. Напротив, REST API позволяют выполнять определенные операции с данными на удаленном сервере. Например, приложение может добавлять или изменять данные сотрудников на удаленном сервере с помощью REST API.
В чем сходство систем RPC и REST?
Удаленный вызов процедур (RPC) и REST – это способы разработки API. API являются неотъемлемой частью современного веб-проектирования и других распределенных систем. С их помощью два отдельных распределенных приложения или сервиса могут взаимодействовать, не обладая информацией о внутреннем устройстве друг друга. Эти два приложения или сервиса могут не иметь практически ничего общего, за исключением обмена небольшим объемом данных.
API также являются стандартным механизмом взаимодействия внутренней части программы (логического компонента) с ее внешней частью (компонентом интерфейса). При разработке веб-страниц и веб-приложений с использованием API вместо сильной взаимозависимости обеспечивается возможность их масштабирования и изменения с меньшим переписыванием кода.
Далее мы обсудим другие сходства между RPC API и REST API.
Абстрагирование
Несмотря на то, что сетевые взаимодействия являются основной целью API, сам процесс взаимодействия на нижнем уровне упрощен для разработчиков API. Таким образом, они могут сосредоточиться на функциях, а не на технической реализации.
Связь
И REST, и RPC используют HTTP в качестве базового протокола. Самые популярные форматы сообщений в системах RPC и REST – JSON и XML. Предпочтение отдается JSON из-за его читабельности и гибкости.
Совместимость с другими языками
Разработчики могут внедрить RESTful API или RPC API на любом языке по своему выбору. Если элемент сетевого взаимодействия API соответствует стандарту интерфейса RESTful или RPC, то остальной код можно писать на любом языке программирования.
Принципы архитектуры RPC и REST
Во время удаленного вызова процедур (RPC) клиент выполняет удаленный вызов функции (также известной как метод или процедура) на сервере. Как правило, во время вызова на сервер передается одно или несколько значений данных.
В отличие от этого, клиент системы REST запрашивает у сервера выполнение действия над определенным ресурсом сервера. Такие действия ограничиваются операциями создания, чтения, обновления и удаления (CRUD), которые передаются в виде команд или методов HTTP.
RPC фокусируется на функциях или действиях, а REST – на ресурсах или объектах.
Принципы RPC
Далее мы обсудим некоторые принципы, которым обычно следуют системы RPC. Однако они не стандартизированы, как в системе REST.
Удаленный вызов
Вызов функции в RPC осуществляется клиентом на удаленном сервере так, как если бы она была вызвана локально.
Передача параметров
Клиент обычно передает параметры в серверную функцию, аналогично локальной функции.
Заглушки
Функции-заглушки существуют как на стороне клиента, так и на стороне сервера. На стороне клиента они вызывают функцию, а на стороне сервера – фактическую функцию.
Принципы REST
Принципы REST стандартизированы. REST API должны соответствовать этим принципам, чтобы их можно было классифицировать как RESTful.
Клиент-сервер
Архитектура REST типа «клиент-сервер» разделяет клиентов и серверы, и они рассматриваются как самостоятельные системы.
Фиксация состояния
Сервер не хранит никаких записей о состоянии клиента между клиентскими запросами.
Кэшируемость
Клиентские или посреднические системы могут кэшировать ответы сервера в зависимости от того, указал ли клиент такую возможность.
Многоуровневая система
Между клиентом и сервером могут существовать посредники. И клиент, и сервер ничего о них не знают и работают так, как если бы они были соединены напрямую.
Единый интерфейс
Клиент и сервер взаимодействуют с помощью стандартизированного набора инструкций и форматов обмена сообщениями в REST API. Ресурсы идентифицируются по их URL-адресам, которые называются адресами REST API.
Как функционируют RPC и REST
При удаленном вызове процедур (RPC) клиент использует команду POST по протоколу HTTP для вызова определенной функции по ее имени. Для работы RPC разработчикам на стороне клиента необходимо заранее знать имя и параметры функции.
В REST для выполнения процедур клиенты и серверы используют такие HTTP-команды, как GET, POST, PATCH, PUT, DELETE и OPTIONS. Разработчикам нужно знать только URL-адреса ресурсов сервера и не беспокоиться об именах отдельных функций.
В таблице показан тип кода, который использует клиент для выполнения аналогичных действий в RPC и REST.
| Работа |
RPC |
REST |
Комментарий |
| Добавление нового продукта в список товаров |
POST /addProduct HTTP/1.1 ХОСТ: api.example.com Тип контента: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /products HTTP/1.1 ХОСТ: api.example.com Тип контента: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
Команда POST используется в RPC для функции, а POST в REST – для URL-адреса. |
| Получение сведений о продукте |
POST /getProduct HTTP/1.1 ХОСТ: api.example.com Тип контента: application/json {"productID": "123”} |
GET /products/123 HTTP/1.1 ХОСТ: api.example.com |
Команда POST используется в RPC для функции и передает параметр в виде объекта формата JSON. Команда GET используется в REST для URL-адреса и передает параметр в виде такого адреса. |
| Обновление цены на продукт |
POST /updateProductPrice HTTP/1.1 ХОСТ: api.example.com Тип контента: application/json {"productId": "123", "newPrice": "20.00"} |
PUT /products/123 HTTP/1.1 ХОСТ: api.example.com Тип контента: application/json {"price": "20.00"} |
Команда POST используется в RPC для функции и передает параметр в виде объекта формата JSON. Команда PUT используется в REST для URL-адреса и передает параметр в виде такого адреса и в виде объекта формата JSON. |
| Удаление продукта |
POST /deleteProduct HTTP/1.1 ХОСТ: api.example.com Тип контента: application/json {"productId": "123""} |
DELETE /products/123 HTTP/1.1 ХОСТ: api.example.com |
Команда POST используется в RPC для функции и передает параметр в виде объекта формата JSON. Команда DELETE используется в REST для URL-адреса и передает параметр в виде такого адреса. |
Ключевые отличия от REST
Далее приведены некоторые другие различия.
Время разработки
Технология RPC была разработана в конце 1970-х – начале 1980-х годов, в то время как термин REST впервые ввел в обиход компьютерный ученый Рой Филдинг в 2000 году.
Операционный формат
REST API имеет стандартизированный набор серверных операций благодаря методам HTTP, а RPC API нет. В некоторых реализациях RPC обеспечивается платформа для стандартизированных операций.
Формат передачи данных
REST может передавать любой формат данных и несколько форматов, например JSON и XML, в одном API.
Однако в RPC API формат данных выбирается сервером и устанавливается в процессе реализации. Вы можете использовать конкретные реализации JSON RPC или XML RPC, в то время как клиенту не предоставляется такая возможность.
Штат
В контексте API термин без фиксации состояний означает принцип проектирования, согласно которому на сервере не хранится никакая информация о предыдущих взаимодействиях клиента. Каждый запрос API обрабатывается независимо, и сервер не полагается на сохраненное состояние клиента для обработки запроса.
Системы REST всегда должны работать без фиксации состояния, а системы RPC могут как сохранять, так и не сохранять его, в зависимости от особенностей архитектуры.
Когда использовать RPC, а когда – REST
Удаленный вызов процедур (RPC) обычно используется для вызова удаленных функций на сервере, требующих результата действия. Этот сервис можно использовать, когда требуются сложные вычисления или вы хотите запустить удаленную процедуру на сервере, скрыв процесс от клиента.
Ниже перечислены действия, для которых RPC подходит наилучшим образом.
- Съемка с помощью камеры удаленного устройства.
- Использование на сервере алгоритма машинного обучения для выявления мошенничества.
- Перевод денег с одного счета на другой в системе дистанционного банковского обслуживания.
- Удаленный перезапуск сервера.
REST API обычно используется для выполнения операций создания, чтения, обновления и удаления (CRUD) объекта данных на сервере. Таким образом, REST API хорошо подходят для случаев, когда требуется единообразное представление серверных данных и структур данных.
Ниже перечислены действия, для которых REST API подходит наилучшим образом.
- Добавление продукта в базу данных.
- Извлечение данных из списка воспроизведения музыки
- Обновление адреса человека.
- Удаление записи в блоге.
Почему REST заменяет RPC?
Хотя REST веб-API сегодня считаются нормой, вызов удаленных процедур (RPC) никуда не исчез. REST API чаще всего используется в приложениях, поскольку разработчикам проще понять и внедрить его. Однако RPC все еще существует и используется, когда больше подходит для конкретного случая.
В настоящее время более популярны современные реализации RPC, такие как gRPC. В некоторых примерах использования архитектура gRPC работает лучше, чем RPC и REST. Она позволяет осуществлять потоковое взаимодействие между клиентом и сервером, а не обмен данными по схеме «запрос-ответ».
Краткое описание различий RPC и REST
| RPC |
REST |
|
| Что это |
Система, позволяющая удаленному клиенту вызвать процедуру на сервере так, как если бы она была локальной. |
Набор правил, определяющих структурированный обмен данными между клиентом и сервером. |
| Используется для |
Выполнения действий на удаленном сервере. |
Операций создания, чтения, обновления и удаления (CRUD) на удаленных объектах. |
| Лучше всего применять |
Когда требуются сложные вычисления или запуск удаленного процесса на сервере. |
Когда требуется единообразное представление серверных данных и структур данных. |
| Фиксация состояния |
С фиксацией состояния или без нее. |
Без фиксации состояния. |
| Формат передачи данных |
В последовательной структуре, определяемой сервером и обязательной для клиента. |
В структуре, определяемой сервером самостоятельно. В пределах одного API можно передавать различные форматы. |
Как AWS обеспечивает соответствие вашим требованиям к API?
Amazon Web Services (AWS) предлагает ряд сервисов и инструментов, с помощью которых разработчики API могут создавать, запускать современные приложения и сервисы на основе API и управлять ими. Дополнительные сведения см. в статье о создании современных приложений на AWS.
Инструменты AWS, которые могут удовлетворить ваши требования к API:
- Amazon API Gateway предоставляет разработчикам возможность создавать, публиковать API и управлять ими в любом масштабе. С помощью API Gateway можно создавать REST API, оптимизированные для контейнерных микросервисных архитектур и веб-приложений.
- Elastic Load Balancing (ELB) распределяет сетевой трафик для улучшения масштабируемости приложений. Этот инструмент может маршрутизировать и балансировать трафик gRPC между микросервисами или клиентами и службами с поддержкой gRPC, что позволяет легко внедрять управление трафиком gRPC в архитектуры без изменения базовой инфраструктуры клиентов или их сервисов.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice – это сетевой сервис приложений, который обеспечивает постоянное подключение, мониторинг и защиту связи между сервисами. Он автоматически масштабирует вычислительные и сетевые ресурсы для поддержки рабочих нагрузок HTTP, HTTPS и gRPC с высокой пропускной способностью.
Создайте аккаунт прямо сейчас и начните работу с REST API и RPC API на AWS.
