У меня есть веб-служба, которая принимает параметры JSON и имеет определенные URL-адреса для методов, например:
http://IP:PORT/API/getAllData?p={JSON}
Это определенно не REST, поскольку это не апатрид. Он принимает во внимание файлы cookie и имеет свой собственный сеанс.
Это RPC? В чем разница между RPC и REST?
Ответы:
Вы не можете четко разделить REST и RPC, просто посмотрев на то, что вы опубликовали.
Одним из ограничений REST является то, что он не должен иметь состояния. Если у вас есть сеанс, у вас есть состояние, поэтому вы не можете вызывать свою службу RESTful.
Тот факт, что у вас есть действие в URL-адресе (т.е. getAllData), указывает на RPC. В REST вы обмениваетесь представлениями, и выполняемая вами операция продиктована глаголами HTTP. Кроме того, в REST согласование содержимого не выполняется с ?p={JSON}параметром.
Не знаю, является ли ваша служба RPC, но это не RESTful. Вы можете узнать о различиях в Интернете, вот статья, которая поможет вам начать: Разоблачение мифов о RPC и REST . Вы лучше знаете, что внутри вашего сервиса, поэтому сравните его функции с RPC и сделайте собственные выводы.
Рассмотрим следующий пример HTTP API, моделирующих заказы, размещаемые в ресторане.
Размещение заказа:
Получение заказа:
Обновление заказа:
Пример взят из sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc
Как уже говорили другие, ключевое отличие состоит в том, что 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 --------------------------- + ---------------------- --------------- + --------------------------
Примечания
GET /persons/1234), тогда как RPC имеет тенденцию использовать параметры запроса для входных данных функций GET /readPerson?personid=1234).GET /persons?height=tall).POST /signupили POST /personsвключаете данные, описывающие нового человека).Это 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.
например: уровень 3 (HATEOAS):
Ссылка утверждает, что этот объект может быть обновлен таким образом и добавлен таким образом.
Ссылка утверждает, что этот объект можно только читать, и вот как мы это делаем.
Ясно, что отправки данных недостаточно, чтобы стать REST, но следует упомянуть и о том, как запрашивать данные. Но опять же, почему 4 шага? Почему это не может быть только шаг 4 и называть его REST? Ричардсон просто предложил нам поэтапный подход к достижению цели, вот и все.
Вы создали веб-сайты, которыми могут пользоваться люди. Но можете ли вы также создавать веб-сайты, которые можно использовать на машинах? За этим будущее, и RESTful Web Services покажет вам, как это сделать.
PS: REST очень популярен, поэтому автоматизированное тестирование является очень популярным, но когда дело касается реальных примеров ... ну ...
REST лучше всего описывать для работы с ресурсами, тогда как RPC больше касается действий.
REST означает передачу состояния представления. Это простой способ организовать взаимодействие между независимыми системами. Приложения RESTful обычно используют HTTP-запросы для публикации данных (создания и / или обновления), чтения данных (например, выполнения запросов) и удаления данных. Таким образом, REST может использовать HTTP для всех четырех операций CRUD (создание / чтение / обновление / удаление).
RPC в основном используется для связи между различными модулями для обслуживания запросов пользователей. например, в openstack, как nova, glance и нейтрон работают вместе при загрузке виртуальной машины.
Я бы сказал так:
Моя организация хранит / владеет данными? Затем RPC: вот копия некоторых моих данных, манипулируйте копией данных, которую я отправляю вам, и верните мне копию вашего результата.
Содержит ли вызываемый объект данные / владеет ли ими? Затем REST: либо (1) показать мне копию некоторых ваших данных, либо (2) манипулировать некоторыми из ваших данных.
В конечном итоге все зависит от того, какая «сторона» действия владеет данными. И да, вы можете использовать словоблудие REST для общения с системой на основе RPC, но при этом вы все равно будете выполнять действия RPC.
Пример 1. У меня есть объект, который обменивается данными с хранилищем реляционной базы данных (или хранилищем данных любого другого типа) через DAO. Имеет смысл использовать стиль REST для этого взаимодействия между моим объектом и объектом доступа к данным, который может существовать как API. Моя сущность не владеет / не хранит данные, в отличие от реляционной базы данных (или нереляционного хранилища данных).
Пример 2: Мне нужно выполнить много сложных математических расчетов. Я не хочу загружать кучу математических методов в свой объект, я просто хочу передать некоторые значения чему-то еще, что может выполнять все виды математики, и получить результат. Тогда стиль RPC имеет смысл, потому что математический объект / сущность предоставит моему объекту целый ряд операций. Обратите внимание, что все эти методы могут быть представлены как отдельные API, и я могу вызвать любой из них с помощью GET. Я даже могу утверждать, что это RESTful, потому что я вызываю через HTTP GET, но на самом деле это RPC. Моя сущность владеет / хранит данные, удаленная сущность просто выполняет манипуляции с копиями данных, которые я ей отправил.
Здесь есть много хороших ответов. Я бы по-прежнему отсылал вас к этому блогу Google, поскольку он действительно хорошо обсуждает различия между RPC и REST и фиксирует то, что я не читал ни в одном из ответов здесь.
Я бы процитировал абзац из той же ссылки, которая мне выдалась:
Сам REST - это описание принципов проектирования, лежащих в основе HTTP и всемирной паутины. Но поскольку HTTP является единственным коммерчески важным REST API, мы можем по большей части не обсуждать REST и сосредоточиться только на HTTP. Эта замена полезна, потому что существует много путаницы и разнообразия в том, что люди думают, что означает REST в контексте API, но есть гораздо большая ясность и согласие относительно того, что такое HTTP сам. Модель HTTP - это полная противоположность модели RPC: в модели RPC адресуемыми единицами являются процедуры, а объекты проблемной области скрыты за процедурами. В модели HTTP адресуемые единицы являются самими объектами, а поведение системы скрыто за объектами как побочные эффекты их создания, обновления или удаления.
Вот как я их понимаю и использую в разных случаях использования:
Пример: Управление рестораном
пример использования 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