Различия веб-сервисов между REST и RPC

108

У меня есть веб-служба, которая принимает параметры JSON и имеет определенные URL-адреса для методов, например:

http://IP:PORT/API/getAllData?p={JSON}

Это определенно не REST, поскольку это не апатрид. Он принимает во внимание файлы cookie и имеет свой собственный сеанс.

Это RPC? В чем разница между RPC и REST?

web-services rest rpc Mazmart
источник
1
Почему это важно, REST или RPC? По какой причине вы спрашиваете?
Богдан
5
Служба не моя, и в ней указано, что это REST, но похоже, что это не так. Я хотел узнать, не ошибаюсь ли я в том, что это не REST.
Mazmart 09
115
@ Богдан знание - причина.
Сэр,
1
@Bogdan - Я боюсь приступа иронии и рекурсивной кроличьей норы, но с какой стати вы спрашиваете, почему он спросил?
Glowkeeper
@glowkeeper: Я хотел понять контекст вопроса, чтобы узнать, как лучше сформулировать ответ.
Богдан

Ответы:

75

Вы не можете четко разделить REST и RPC, просто посмотрев на то, что вы опубликовали.

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

Тот факт, что у вас есть действие в URL-адресе (т.е. getAllData), указывает на RPC. В REST вы обмениваетесь представлениями, и выполняемая вами операция продиктована глаголами HTTP. Кроме того, в REST согласование содержимого не выполняется с ?p={JSON}параметром.

Не знаю, является ли ваша служба RPC, но это не RESTful. Вы можете узнать о различиях в Интернете, вот статья, которая поможет вам начать: Разоблачение мифов о RPC и REST . Вы лучше знаете, что внутри вашего сервиса, поэтому сравните его функции с RPC и сделайте собственные выводы.

Богдан
источник
так что RESTful означает, что он подчиняется всем стандартам, кроме REST, когда он может не подчиняться стандартам ?.
Mazmart 09
5
@Mazmart: REST - это набор правил и ограничений. Это не спецификация, которую можно реализовать, и когда они утверждают, что у них есть служба RESTful. Из того, что я заметил, в большинстве случаев люди называют REST все, что не является SOAP , хотя на самом деле это просто какой-то другой вид RPC.
Богдан
131

Рассмотрим следующий пример HTTP API, моделирующих заказы, размещаемые в ресторане.

  • RPC API думает в терминах «глаголы», обнажая функциональность ресторана , как вызовы функций , которые принимают параметры, и вызывает эти функции с помощью HTTP глагол , который кажется наиболее подходящим - это «получить» для запроса, и так далее, но имя глагола является чисто случайным и не имеет реального отношения к реальной функциональности, поскольку вы каждый раз вызываете другой URL-адрес . Коды возврата кодируются вручную и являются частью контракта на обслуживание.
  • REST API , в отличии от модели различных объектов в пределах проблемной области как ресурсы и использование HTTP глаголов для представления операций против этих ресурсов - POST для создания, PUT для обновления и GET для чтения. Все эти команды, вызываемые по одному и тому же URL-адресу , обеспечивают разную функциональность. Общие коды возврата HTTP используются для передачи статуса запросов.

Размещение заказа:

Получение заказа:

Обновление заказа:

Пример взят из sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc

ГорвГойл
источник
34
Наконец, несколько примеров URL.
Фабиан Пиконе
4
Я не согласен с тем, что вы говорите относительно URL-адресов. Вы можете иметь все вызовы RPC по одному и тому же URL-адресу, а REST по разным URL-адресам. Вы показываете только одну сторону медали.
basickarl 03
То, что вы здесь описываете, не является REST - REST - это архитектурный паттерн. Вы описываете REST через HTTP, о чем думает большинство людей, когда они говорят о REST.
d4nyll
40

Как уже говорили другие, ключевое отличие состоит в том, что REST ориентирован на существительное, а RPC - на глагол. Я просто хотел включить эту четкую таблицу примеров, демонстрирующих, что:

--------------------------- + ---------------------- --------------- + --------------------------
  Операция                  | RPC (операция)                      | ОТДЫХ (ресурс)
--------------------------- + ---------------------- --------------- + --------------------------
 Регистрация | POST / регистрация | ПОЧТА / чел.           
--------------------------- + ---------------------- --------------- + --------------------------
 В отставку | POST / уйти в отставку | УДАЛИТЬ / человек / 1234    
--------------------------- + ---------------------- --------------- + --------------------------
 Прочитать человека | GET / readPerson? Personid = 1234 | GET / человек / 1234       
--------------------------- + ---------------------- --------------- + --------------------------
 Прочитать список предметов | GET / readUsersItemsList? Userid = 1234 | GET / человек / 1234 / предметы
--------------------------- + ---------------------- --------------- + --------------------------
 Добавить элемент в список людей | POST / addItemToUsersItemsList | POST / person / 1234 / items
--------------------------- + ---------------------- --------------- + --------------------------
 Обновить элемент | POST / modifyItem | PUT / items / 456          
--------------------------- + ---------------------- --------------- + --------------------------
 Удалить элемент | POST / removeItem? ItemId = 456 | УДАЛИТЬ / items / 456       
--------------------------- + ---------------------- --------------- + --------------------------

Примечания

  • Как показано в таблице, REST имеет тенденцию использовать параметры пути URL для идентификации конкретных ресурсов
    (например GET /persons/1234), тогда как RPC имеет тенденцию использовать параметры запроса для входных данных функций
    (например GET /readPerson?personid=1234).
  • В таблице не показано, как REST API будет обрабатывать фильтрацию, которая обычно включает параметры запроса (например GET /persons?height=tall).
  • Также не показано, как с любой системой, когда вы выполняете операции создания / обновления, дополнительные данные, вероятно, передаются через тело сообщения (например, когда вы это делаете POST /signupили POST /personsвключаете данные, описывающие нового человека).
  • Конечно, ничего из этого не высечено в камне, но это дает вам представление о том, с чем вы, вероятно, столкнетесь, и как вы можете организовать свой собственный API для обеспечения согласованности. Для дальнейшего обсуждения дизайна URL-адреса REST см. Этот вопрос .
MarredCheese
источник
32

Это RPC с использованием http . Правильная реализация REST должна отличаться от RPC. Чтобы иметь логику для обработки данных, такую ​​как метод / функция, это RPC. getAllData () - интеллектуальный метод. REST не может иметь интеллекта, это должны быть данные дампа, которые может запрашивать внешний интеллект .

Большинство реализаций, которые я видел в эти дни, - это RPC, но многие ошибочно называют его REST. REST с HTTP - это спаситель, а SOAP с XML - злодей. Значит, ваше замешательство оправдано и вы правы, это не ОТДЫХ.

Протокол Http не реализует REST. И REST (GET, POST, PUT, PATCH, DELETE), и RPC (GET + POST) могут быть разработаны через HTTP (например, через проект веб-API в Visual Studio).

Хорошо, но что тогда такое REST? Модель зрелости Ричардсона представлена ​​ниже (вкратце). Только уровень 3 - RESTful.

  • Уровень 0: Http POST
  • Уровень 1: у каждого ресурса / объекта есть URI (но все еще только POST)
  • Уровень 2: можно использовать как POST, так и GET.
  • Уровень 3 (RESTful): использует HATEOAS (гиперссылки на медиа) или, другими словами, самоисследовательные ссылки.

например: уровень 3 (HATEOAS):

  1. Ссылка утверждает, что этот объект может быть обновлен таким образом и добавлен таким образом.

  2. Ссылка утверждает, что этот объект можно только читать, и вот как мы это делаем.

    Ясно, что отправки данных недостаточно, чтобы стать REST, но следует упомянуть и о том, как запрашивать данные. Но опять же, почему 4 шага? Почему это не может быть только шаг 4 и называть его REST? Ричардсон просто предложил нам поэтапный подход к достижению цели, вот и все.

Вы создали веб-сайты, которыми могут пользоваться люди. Но можете ли вы также создавать веб-сайты, которые можно использовать на машинах? За этим будущее, и RESTful Web Services покажет вам, как это сделать.

PS: REST очень популярен, поэтому автоматизированное тестирование является очень популярным, но когда дело касается реальных примеров ... ну ...

Синие облака
источник
1
Первый абзац объясняет разницу очень простым и понятным образом.
Николас Хараламбидис
15

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

REST означает передачу состояния представления. Это простой способ организовать взаимодействие между независимыми системами. Приложения RESTful обычно используют HTTP-запросы для публикации данных (создания и / или обновления), чтения данных (например, выполнения запросов) и удаления данных. Таким образом, REST может использовать HTTP для всех четырех операций CRUD (создание / чтение / обновление / удаление).

RPC в основном используется для связи между различными модулями для обслуживания запросов пользователей. например, в openstack, как nova, glance и нейтрон работают вместе при загрузке виртуальной машины.

IRSHAD
источник
4

Я бы сказал так:

Моя организация хранит / владеет данными? Затем RPC: вот копия некоторых моих данных, манипулируйте копией данных, которую я отправляю вам, и верните мне копию вашего результата.

Содержит ли вызываемый объект данные / владеет ли ими? Затем REST: либо (1) показать мне копию некоторых ваших данных, либо (2) манипулировать некоторыми из ваших данных.

В конечном итоге все зависит от того, какая «сторона» действия владеет данными. И да, вы можете использовать словоблудие REST для общения с системой на основе RPC, но при этом вы все равно будете выполнять действия RPC.

Пример 1. У меня есть объект, который обменивается данными с хранилищем реляционной базы данных (или хранилищем данных любого другого типа) через DAO. Имеет смысл использовать стиль REST для этого взаимодействия между моим объектом и объектом доступа к данным, который может существовать как API. Моя сущность не владеет / не хранит данные, в отличие от реляционной базы данных (или нереляционного хранилища данных).

Пример 2: Мне нужно выполнить много сложных математических расчетов. Я не хочу загружать кучу математических методов в свой объект, я просто хочу передать некоторые значения чему-то еще, что может выполнять все виды математики, и получить результат. Тогда стиль RPC имеет смысл, потому что математический объект / сущность предоставит моему объекту целый ряд операций. Обратите внимание, что все эти методы могут быть представлены как отдельные API, и я могу вызвать любой из них с помощью GET. Я даже могу утверждать, что это RESTful, потому что я вызываю через HTTP GET, но на самом деле это RPC. Моя сущность владеет / хранит данные, удаленная сущность просто выполняет манипуляции с копиями данных, которые я ей отправил.

Джон Таллис
источник
3

По протоколу HTTP они оба становятся просто HttpRequestобъектами, и оба ожидают HttpResponseвозврата объекта. Я думаю, что можно продолжить кодирование с этим описанием и беспокоиться о другом.

Acmoune
источник
2

Здесь есть много хороших ответов. Я бы по-прежнему отсылал вас к этому блогу Google, поскольку он действительно хорошо обсуждает различия между RPC и REST и фиксирует то, что я не читал ни в одном из ответов здесь.

Я бы процитировал абзац из той же ссылки, которая мне выдалась:

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

Мистер Матрица
источник
1

Вот как я их понимаю и использую в разных случаях использования:

Пример: Управление рестораном

пример использования REST : управление заказами

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

Для управления ресурсами REST чист. Одна конечная точка с предопределенными действиями. Можно увидеть способ предоставить миру экземпляры БД (Sql или NoSql) или классов.

Пример реализации: 

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

Пример фреймворка: Falcon для Python.

вариант использования RPC : управление операциями

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

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

Пример реализации:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

Пример фреймворка: Flask для Python

Али Хосро
источник