Что классифицировано как УСПОКОИТЕЛЬНЫЙ веб-сервис

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

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

HTTP GET для такого URL-адреса www.example.com/service.asmx?param1=1¶m2=2

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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