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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

• RPC: http://MyRestaurant:8080/Orders/PlaceOrder (POST: {Tacos object})
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (POST: {Tacos object})

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

• RPC: http://MyRestaurant:8080/Orders/GetOrder?OrderNumber=asdf (GET)
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (GET)

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

• RPC: http://MyRestaurant:8080/Orders/UpdateOrder (PUT: {объект ананаса Tacos})
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (PUT: {объект ананаса Tacos})

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

Ответ 3

Как уже говорили другие, ключевое отличие состоит в том, что 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       
---------------------------+-------------------------------------+--------------------------

Заметки

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

Ответ 4

Это 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 - ОТДЫХ.

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

например, уровень 3:

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

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

• Эта книга RESTful Web Services помогает
• Очень интересное чтение RPC против REST

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

сценарий использования 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

Ответ 8

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