Что отличает веб-сервис REST от RPC-подобного?

Question

У меня есть веб-приложение, которое использует AJAX для получения данных JSON с сервера. Это требует, чтобы пользователь сначала вошел в систему с помощью своего браузера, чтобы можно было установить cookie. Используются только глаголы GET и POST, где GET для извлечения данных и POST для любой операции, которая изменяет данные.

Из того, что я понимаю, REST отличается от вышеописанного метода тем, что информация аутентификации пользователя отправляется с каждым запросом, а также используются глаголы PUT и DELETE.

У меня вопрос: какие преимущества имеет веб-служба REST по сравнению с RPC-подобным методом, если конечная точка предназначена только для браузера пользователя? Я могу понять, насколько полезен REST, когда клиент неизвестен, но когда я использую только jjuery-вызовы ajax, все же стоит ли это преимущество перед RPC-подобным методом?

Answer 1

Одно из больших различий между REST и RPC заключается в том, что REST связан с ресурсами, а RPC - с действиями. Например, с действительно RESTful-сервисом вы бы никогда не назвали что-то вроде http://domain.com/service/User/jason/add или http://domain.com/service/User/addUser?username=jason.. С помощью RESTful-службы вы всегда ссылаетесь только на ресурс в URL, а затем определяете, что делать с этим ресурсом, используя HTTP глаголы и тело запроса. Поэтому запрос GET по адресу http: /domain.com/service/jason должен возвращать информацию о ресурсе (пользователь jason). Вы можете получить более конкретную информацию и сказать http://domain.com/service/user/jason, но результат должен быть таким же. Если бы вы добавляли пользователя с именем jason, вы бы использовали точно такой же URL http://domain.com/service/user/jason, но вы бы использовали глагол PUT, а тело запроса содержало бы дополнительные данные. Чтобы удалить ресурс jason, вы снова должны использовать тот же URL (http://domain.com/service/user/jason) и использовать глагол DELETE. Для обновления вы должны использовать глагол POST.

REST отлично подходит для общедоступных API-интерфейсов, которые вы собираетесь использовать другим разработчикам. Их можно сделать очень стандартными, чтобы им не требовалось тонны уже существующих знаний об услуге. Нет вызовов WSDL и т. Д. Из-за отсутствия состояния он также может сделать их более стабильными во время частичных сбоев сети.

Из того, что вы описываете, я не думаю, что вам нужен действительно RESTful сервис. Но вы, возможно, захотите рассмотреть, если вам когда-нибудь понадобится более стандартный API. Я сделал REST-сервис для проекта, который я использую только для внутреннего использования, но это потому, что я намеревался получить доступ к этому сервису, возможно, из десятков других сервисов, а в будущем, возможно, от других разработчиков. Поэтому, хотя поначалу я использовал его только для пары проектов, конечная цель требовала более стандартного интерфейса.

Answer 2

Думайте об этом так - важна ли эта функция или какая информация используется?

Когда вы имеете дело с REST, вы находитесь в состоянии состояния информации - вы смотрите, какая текущая информация (GET), или вы изменяете этот конкретный документ (POST, DELETE), или вы создаете новый документ (PUT).

В RPC речь идет о процедурах / функциях / методах / операциях ... как бы вы их ни называли на своем языке. Информация - это то, что обрабатывается или возвращается службой ... но может быть одним из многих. Возможно, мы ищем и возвращаем список товаров. Или мы могли бы вести переговоры о чем-то, где нам нужно какое-то взаимодействие назад и вперед. (Переговоры REST по большей части обрабатываются через HTTP, поэтому вы должны делать что-то с заголовками Accept и Accept-Language) Но важнее всего эта операция.

Тогда есть третий тип, который является документом / литералом SOAP ..., где важно сообщение, и вы должны догадаться, что вызываемая функция основана на сообщении. Если вы просто имеете дело с операциями CRUD, это, вероятно, хорошо. Преимущества по сравнению с REST в этом случае в том, что у вас все еще может быть WSDL, поэтому вы заранее знаете, какие элементы необходимо отправить и что ожидать в ответ.

Они все работают ... это в основном о том, как вы думаете о проблеме, и как легко конвертировать из того, что вы уже представляете, как API. Если вы начинаете с нуля, вы можете делать все, что захотите. Мне лично нравится SOAP (либо document / lit, либо RPC) в том смысле, что я могу дать файл WSDL, который кто-то может использовать для начальной загрузки своего клиента. У меня были случаи, когда люди делали серьезные запросы в течение нескольких часов. (объяснение некоторых абстрактных тонкостей API, таких как разница между отправкой пустой строки и нулевой, заняло некоторое время, но у меня были бы те же проблемы с REST) ​​

Answer 3

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

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

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

REST / RPC:

В качестве подхода к программированию REST является легкой альтернативойна веб-сервисы и RPC.Подобно веб-службам, служба REST:

1. Независимо от платформы (вам не важно, является ли сервер Unix, клиент Mac или что-то еще),
2. Независимый от языка (C # может общаться с Java и т. Д.),
3. Основанный на стандартах (работает поверх HTTP), и
4. Может легко использоваться при наличии брандмауэров.

Answer 4

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

Я утверждаю, что REST over HTTP с jsons являются формой RPC.

другие популярные RPC могут включать SOAP, например

Answer 5

Вы правы в том, что REST менее связан с вызывающим объектом - если вы сравниваете с веб-службой SOAP, для которой требуется, чтобы файл WSDL вызывался с сервера, чем да, веб-службы REST менее связаны (т.е. не требуютзнание веб-сервиса до его вызова).И большую часть времени токен должен быть передан вместе с запросом на данное «представление».

Я не думаю, что использование REST от ajax приносит огромную выгоду. Фактически, в зависимости от API, с которым вы работаете, вам может потребоваться токен, который передается как параметр URI (параметр querystring)при использовании веб-службы на основе SOAP это необязательно.На самом деле довольно легко объединить веб-сервисы SOAP с вызовами ajax, передать данные в формате JSON и десериализовать JSON в объект на стороне сервера.И в довершение всего, jQuery делает все это очень простым.