Подходит ли REST для веб-сервисов в стиле документа?

Question

RESTful и стиль документа / сообщения, кажется, являются двумя тенденциями для реализации веб-сервисов в настоящее время в целом. Под этим я подразумеваю REST против SOAP и стиль документа против стиля RPC.

Мой вопрос заключается в том, насколько совместим REST с веб-службами в стиле документа. Из моего ограниченного знания REST, он использует http GET / POST / PUT / DELETE глаголы для выполнения CRUD-подобных операций на удаленных ресурсах, обозначаемых URL-адресами, что делает его более «болтливым» и удаленным методом, похожим на RPC стиль. С другой стороны, веб-сервисы в стиле документа делают упор на грубые вызовы, то есть отправляют пакетный документ запроса со сложной информацией и ожидают ответный документ также со сложной информацией. Я не могу понять, как этого можно добиться с помощью REST, не объявляя только один ресурс для «Response» и постоянно используя глагол POST (что побьет цель REST).

Поскольку я новичок в веб-службах как в стиле документа, так и в веб-службах RESTful, прошу извинить меня и любезно указать на любое незнание вышеприведенных предположений. Спасибо!

Answer 1

Ваше понимание REST ошибочно. Это не удивительно, ни ваша вина. В Интернете гораздо больше неверной информации о REST, чем достоверной информации.

REST гораздо больше подходит для типа распределенного интерфейса с грубым типом документа, чем для ориентированного на данные интерфейса CRUD. Хотя между операциями CRUD и HTTP GET / PUT / POST / DELETE есть сходства, существуют тонкие различия, которые очень важны для архитектуры вашего приложения.

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

SOAP обычно используется для «веб-сервисов», а REST обычно выполняется по HTTP.

Answer 2

REST действительно предназначен для использования с документами, если вы считаете свой документ ресурсом.

GET позволяет получить документ. Очевидно.

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

PUT позволяет изменить документ. Опять же, нет необходимости заставлять клиента отправлять весь документ каждый раз, когда он хочет сохранить. Ваш API может поддерживать дельта-обновления, отправляемые с помощью запросов PUT.

УДАЛИТЬ, очевидно, удаляет документ. Опять же, вы можете спроектировать свой API так, чтобы удаление фактически не уничтожало все биты документа. Вы можете создать систему, похожую на корзину.

Что хорошо для REST и работы с документами, так это то, что ответ сервера содержит всю информацию, необходимую для понимания ответа. Поэтому, если новый ресурс создан, вы должны отправить его местоположение, то же самое, если ресурс перемещен и т. Д. Все, что вам нужно документировать, - это типы данных, которые будут использоваться (форматы XML, JSON и т. Д.)

Стандартные методы HTTP существуют только потому, что их поведение уже определено и позволяет клиентам легко обнаруживать ваш API, если они знают URI.