Что классифицируется как веб-сервис RESTful

Question

Итак, в настоящее время у меня есть приложение, которое вызывает веб-сервис для извлечения данных, где я делаю простой HTTP GET по URL-адресу, например, так Это возвращает некоторый XML, который я анализирую.

Мой вопрос: классифицирует ли это его как веб-сервис RESTful? Я думаю нет, но я хотел бы знать, что делает его веб-сервисом REST?

Я знаю, что есть веб-сервисы REST и SOAP, но что можно было бы классифицировать как простой веб-сервис HTTP GET? или что?

Спасибо, я пытаюсь сопоставить терминологию с понятиями, простите, если это слишком элементарно.

Answer 1

Прямой ответ на ваш вопрос - нет.

Рассказывая о том, что вы сказали нам о своем обслуживании, я расскажу о том, что не подходит для вашего решения.

HTTP GET на URL вроде так www.example.com/service.asmx?param1=1&param2=2

Вы используете HTTP GET и поэтому используете один из ограниченного набора глаголов для доступа к какому-либо ресурсу через URI. Это RESTful и соответствует унифицированному ограничению интерфейса, если сервер не нарушает ни одно из правил HTTP о том, что GET разрешено делать.

Глядя на сам URL-адрес, неясно, к какому ресурсу вы обращаетесь, и поэтому он намекает на то, что ваше пространство URL-адресов не может быть структурировано таким образом, который удобен для создания дизайна RESTful. Тем не менее, REST не накладывает никаких ограничений на то, как должен выглядеть ваш URL (несмотря на то, что многие считают soooooooo), поэтому в вашем URL нет ничего плохого.

Это возвращает некоторый xml, который я анализирую.

Вот тут и начинаются твои проблемы. В этом утверждении я неявно читаю, что клиент знает, как анализировать данные из вашего XML. Это нарушение самоописательного ограничения REST. Сообщение http должно содержать всю информацию, необходимую клиенту, чтобы знать, как обрабатывать ответ на запрос. Тип носителя должен сообщать клиенту, какая информация содержится в документе XML. Если ваш сервис возвращает application / xml, единственное, что клиент знает, это то, что документ содержит атрибуты и элементы. Если клиент использует внеполосные знания для анализа этого XML, то вы вводите связь между клиентом и сервером. Одна из основных целей REST - устранить эту связь.

Существует ряд других ограничений, которые служба должна соблюдать, чтобы ее считали RESTful, но вы не предоставляете достаточно подробную информацию о своей услуге, чтобы так или иначе сказать, если она соответствует требованиям.

Answer 2

Прямой ответ на ваш вопрос: Я не знаю .
Предоставленная вами информация о вашем веб-сервисе недостаточно точна, чтобы классифицировать его как веб-сервис RESTful.

REST - это архитектурный стиль (не метод проектирования или реализации), это означает, что вы должны следовать его принципам в архитектуре вашего программного обеспечения, чтобы классифицировать его как RESTful:

• Клиент / Сервер с четко определенным и унифицированным интерфейсом
  • Единая идентификация ресурсов
  • Манипулирование этими ресурсами через их представление
  • Самописные сообщения: каждое сообщение описывает, как обрабатывать данные
  • Гипермедиа как движок состояния приложения: переходы между состояниями осуществляются по следующим ссылкам
• Stateless
• Кешируемость ресурсов
• Слоистая система

Источником № 1, с которым вы должны ознакомиться, прежде чем делать что-либо RESTful, является кандидатская диссертация Роя Филдинга , "парень, который изобрел REST": -)

Обратите внимание, что REST не определяет схемы URL, но есть некоторые распространенные рекомендации о схемах URL в архитектурах RESTful, например , используемых Rails .

Answer 3

Службы REST - это службы, которые обычно соответствуют следующим требованиям:

• Укажите идентификатор, который точно описывает запрашиваемый ресурс.
• Предоставляет службы, которые работают так, как ожидаемые GET-запросы, являются идемпотентными, POST обновляет записи, PUT создает, DELETE удаляет
• Минимизация состояния, сохраняемого на сервере
• Вообще снести ненужную сложность
• По HTTP (хотя я видел другие реализации, они, конечно, не являются RESTful в традиционном смысле)

Причина, по которой ваш URL-адрес не настолько "успокоительный", каким он может быть, заключается в том, что он содержит неидентифицирующую информацию (например, .ASMX) Кроме того, некоторые считают, что добавление параметров url подходит только для фильтрации. (но это не значит, что использование параметров URL не является RESTful!)

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

Часто сервисы RESTful работают с XML, хотя, опять же, это тоже не жесткое правило.

Answer 4

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

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

Наиболее важной концепцией REST является то, что ваши ресурсы обнаруживаются и перемещаются по гипертексту. Ваш API должен быть описанием ваших типов медиа. Единственный URI в вашем API - это точка входа.

Answer 5

Не думаю, что вы получите окончательный ответ на этот вопрос. И REST, и Web-сервисы - очень запутанные термины, теперь вы их объединяете.

REST может означать,

1. В самых строгих терминах URL должен представлять ресурс, и должен использоваться правильный HTTP-глагол (GEt / PUT / POST / DELETE). У нас есть соглашение здесь. Это записано как ReST, если это означает это.
2. Любой HTTP или веб-протокол, если он использует параметры запроса и форму публикации в запросе.
3. Любой протокол HTTP. Запрос может быть в формате XML или JSON.

Веб-сервисы также имеют несколько значений,

1. Раньше это означало вызовы SOA на основе SOAP.
2. Затем вводятся веб-сервисы в стиле REST. Это в основном вызовы SOA без SOAP. Я даже вижу, как люди используют точное сообщение SOAP без заголовка SOAP.
3. Некоторые люди считают, что WADL (эквивалент WSDL) должен использоваться для классификации в качестве веб-служб, особенно в сообществе JAX-RS.