RESTful-сервисов - язык WSDL эквивалент

WSDL описывает конечные точки службы. Клиенты REST не должны быть связаны с конечными точками сервера (т. е. не должны быть заранее известны в URL-адресах). Клиенты REST соединяются на типах носителей, которые передаются между клиентом и сервером.

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

RSDL стремится превратить rest как гипермедиа, другими словами, он имеет больше информации, чем сервисный дескриптор, такой как WSDL или WADL. Например, он содержит информацию о навигации, например гипертекст и гиперссылки.

например, учитывая текущий ресурс, у вас есть набор ссылок ОС на другие ресурсы, связанные.

однако я не нашел клиентов Rest, которые поддерживают этот формат или решения Rest Server с функцией автоматического его создания.

I думаю, есть долгий путь для вывода об этом. См. длинную историю HTML и W3C против браузеров lol.

для получения более подробной информации об отдыхе, как гипермедиа посмотреть его:http://en.wikipedia.org/wiki/HATEOAS

Примечание: Рой Филдинг критиковал эти тенденции в REST Apis без подхода к гипермидии:http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

мой вывод: Теперь дни, WADL больше распространено, что REST и интеграционные фреймворки, такие как Camel CXF, уже поддерживают WADL ( generate and consume), потому что он похож на WSDL, поэтому наиболее легко понять в этом процессе миграции ( SOAP to REST ).

давайте посмотрим следующие главы;)

существует RSDL (язык описания службы restful), который эквивалентен WSDL. URL ниже описывает свою практику http://en.wikipedia.org/wiki/HATEOAS и http://en.wikipedia.org/wiki/RSDL. Проблема в том, что у нас есть много инструментов для генерации кода из wsdl в java или наоборот. Но я не нашел никакого инструмента для генерации кода из RSDL.

разве не всегда полезно программно привязываться к определению и создавать прокси-классы вместо ручного кодирования?

полностью согласен, именно поэтому я использую чванство.Ио

Swagger-это мощная платформа с открытым исходным кодом, поддерживаемая большим экосистема инструментов, которые помогают разрабатывать, создавать, документировать и использовать ваш спокойный Апис.

поэтому в основном я использую Swagger для описания мои модели, конечные точки и т. д., а затем я использую другие инструменты, такие как чванство-что codegen для генерации прокси-классов вместо ручного кодирования.

Читайте также: РАМЛ

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

однако REST использует сетевой протокол с помощью команд HTTP и URI для представления состояния объектов.

WSDLs скажет вам в этом месте, если вы отправите это сообщение, вы выполните это действие и получите этот формат обратно в результате.

в REST, если бы я хотел создать новый профиль я бы использовал глагол POST с телом JSON или переменными HTTP-сервера, описывающими мой профиль в URL /profile

POST должен возвращать идентификатор, сгенерированный на стороне сервера, используя код состояния 201 CREATED и заголовок Location: *new_profile_id* (например 12345)

затем я могу выполнять обновления, изменяя состояние /profile/12345 использование команды HTTP POST, скажем, изменить адрес электронной почты или номер телефона. Очевидно, изменение состояния пульта объект.

GET вернет текущее состояние /profile/12345

PUT обычно используется для генерируемого ID на стороне клиента

DELETE очевидно

HEAD, получает статус, не возвращая тело.

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

это отличная статья на отдых. Мне это тоже помогает понять.

спецификация wsdl 2.0 также добавила поддержку веб-служб REST. Лучший сценарий обоих миров. Проблема в том, что WSDL 2.0 пока не поддерживается большинством инструментов. WSDL 2.0 рекомендуется W3C, WSDL1.1 Не рекомендуется W3C, но широко поддерживается инструментами и разработчиками. Ссылка: http://www.ibm.com/developerworks/library/ws-restwsdl/

язык описания веб-приложений (WADL) - это словарь XML, используемый для описания веб-служб RESTful.

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

поскольку службы RESTful имеют более простые интерфейсы, WADL не так необходим для этих служб, как WSDL для служб SOAP в стиле RPC.