У меня есть веб-служба, которая принимает параметры 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 и сделайте свои собственные выводы.
Рассмотрим следующий пример API-интерфейсов HTTP, которые моделируют заказы, размещаемые в ресторане.
Размещение заказа:
Получение заказа:
Обновление заказа:
Пример, взятый из sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc
Как уже говорили другие, ключевое отличие состоит в том, что REST ориентирован на существительное, а RPC - на глагол. Я просто хотел включить эту ясную таблицу примеров, демонстрирующих, что:
---------------------------+-------------------------------------+-------------------------- Operation | RPC (operation) | REST (resource) ---------------------------+-------------------------------------+-------------------------- Signup | POST /signup | POST /persons ---------------------------+-------------------------------------+-------------------------- Resign | POST /resign | DELETE /persons/1234 ---------------------------+-------------------------------------+-------------------------- Read person | GET /readPerson?personid=1234 | GET /persons/1234 ---------------------------+-------------------------------------+-------------------------- Read person items list | GET /readUsersItemsList?userid=1234 | GET /persons/1234/items ---------------------------+-------------------------------------+-------------------------- Add item to person list | POST /addItemToUsersItemsList | POST /persons/1234/items ---------------------------+-------------------------------------+-------------------------- Update item | POST /modifyItem | PUT /items/456 ---------------------------+-------------------------------------+-------------------------- Delete item | POST /removeItem?itemId=456 | DELETE /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, потому что они видят, что они не используют XML/Soap, а используют HTTP + json. REST с HTTP является спасителем, а SOAP с XML - злодеем. Таким образом, ваше замешательство оправдано, и вы правы, это не ОТДЫХ.
Протокол HTTP не делает реализацию REST. И REST (GET, POST, PUT, PATCH, DELETE) и RPC (GET + POST) могут быть разработаны через HTTP (например, через проект веб-API в visual studio).
RPC стар, и все школьники знают, что такое RPC, и большая часть разработанного REST заканчивается RPC (HTTP + Json), что понятно. Но что такое ОТДЫХ? Модель зрелости Ричардсона приведена ниже (обобщено). Только уровень 3 - ОТДЫХ.
например, уровень 3:
Вы создали веб-сайты, которые могут быть использованы людьми. Но вы также можете создавать веб-сайты, которые можно использовать на машинах? Это где будущее ложь, и RESTful Web Services покажет вам, как это сделать.
Лучше всего описывать REST для работы с ресурсами, где RPC больше относится к действиям.
REST означает передачу государственного представительства. Это простой способ организовать взаимодействие между независимыми системами. Приложения RESTful обычно используют HTTP-запросы для публикации данных (создания и/или обновления), чтения данных (например, создания запросов) и удаления данных. Таким образом, REST может использовать HTTP для всех четырех операций CRUD (Create/Read/Update/Delete).
RPC в основном используется для связи через разные модули для обслуживания пользовательских запросов. например В openstack, например, как nova, glance и нейтроны работают вместе при загрузке виртуальной машины.
Я бы сказал так:
Сохраняет ли моя сущность/владеет данными? Затем RPC: вот копия некоторых моих данных, манипулируйте копией данных, которую я вам пришлю, и верну мне копию вашего результата.
Является ли вызываемая сущность собственностью/данными? Затем REST: либо (1) покажите мне копию некоторых ваших данных, либо (2) обработайте некоторые ваши данные.
В конечном итоге речь идет о том, какая "сторона" действия владеет/хранит данные. И да, вы можете использовать формулировку REST для общения с RPC-системой, но при этом вы будете делать RPC-активность.
Пример 1: У меня есть объект, который связывается с хранилищем реляционных баз данных (или любым другим типом хранилища данных) через DAO. Имеет смысл использовать стиль REST для этого взаимодействия между моим объектом и объектом доступа к данным, который может существовать как API. Моя сущность не владеет/не держит данные, реляционная база данных (или нереляционное хранилище данных) делает.
Пример 2: Мне нужно сделать много сложной математики. Я не хочу загружать кучу математических методов в свой объект, я просто хочу передать некоторые значения чему-то другому, которые могут выполнять все виды математики, и получить результат. Тогда стиль RPC имеет смысл, потому что математический объект/сущность откроет моему объекту целую цепочку операций. Обратите внимание, что все эти методы могут быть представлены как отдельные API, и я мог бы назвать любой из них с помощью GET. Я даже могу утверждать, что это RESTful, потому что я звоню через HTTP GET, но действительно под обложками это RPC. Мой объект владеет/хранит данные, удаленный объект просто выполняет манипуляции с копиями данных, которые я ему отправил.
Вот как я понимаю и использую их в разных случаях:
Пример: управление рестораном
сценарий использования 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.
Пример фреймворка: Сокол для питона.
сценарий использования для 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
Через HTTP они оба становятся просто объектами HttpRequest и ожидают возврата объекта HttpResponse. Я думаю, что можно продолжать кодирование с этим описанием и беспокоиться о чем-то еще.