Я читал о REST и SOAP и понимаю, почему внедрение REST может быть выгодным с использованием протокола SOAP. Тем не менее, я до сих пор не понимаю, почему в мире REST нет эквивалента «WSDL». Я видел сообщения о том, что «нет необходимости» для WSDL или что он будет лишним. В мире REST, но я не понимаю, почему. Разве не всегда полезно программно привязываться к определению и создавать классы прокси вместо ручного кодирования? Я не собираюсь вступать в философские дебаты, просто ищет причину отсутствия WSDL в REST или почему это не нужно. Благодарю.RESTful Services - WSDL Equivalent
ответ
Web Application Description Language (WADL) в основном эквивалентен WSDL для сервисов RESTful, но существует постоянная разногласия по поводу того, требуется ли вообще что-то подобное.
Joe Gregorio написал a nice article about that topic, который стоит прочитать.
Спасибо Joschi. Я читал статьи, но не нашел второго слишком убедительным. Какие пункты, на которые он обращался, вы считаете наиболее ценными? – skaz
Возможно, стоит отметить, что .NET также имеет возможность публиковать метаданные (http://msdn.microsoft.com/en-us/library/ms730243.aspx). С учетом сказанного, большинство сервисов REST, которые я видел на больших сайтах, включают в себя множество загружаемых клиентов, разработанных для основных языков программирования (Java, .NET, PHP и т. Д.). На мой взгляд, это налагает большую нагрузку на поставщика услуг. – dana
@dana: Кажется, не слишком много написано о службе, которая требует от вас также написать клиенту? – BlueChippy
WSDL описывает конечные точки обслуживания. Клиенты REST не должны соединяться с конечными точками сервера (т. Е. Не должны заранее знать URL-адреса). Клиенты REST привязаны к медиа-типам, которые передаются между клиентом и сервером.
Возможно, имеет смысл автоматически генерировать классы на клиенте для обертывания возвращаемых типов носителей. Однако, как только вы начнете создавать классы-прокси-серверы вокруг взаимодействий служб, вы начинаете скрывать взаимодействия HTTP и риски, вырождающиеся обратно в RPC-модель.
Можете ли вы подробнее рассказать? Боюсь, я этого не понимаю. Благодарю. – skaz
Попробуйте это http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven –
Прокси-классы - это способ проверки машины во время компиляции. Без них у вас есть только письменные документы и тестовая «проверка». –
Однако REST использует сетевой протокол, используя HTTP глаголы и URI для представления состояния объектов.
WSDLs сообщают вам об этом месте, если вы отправите это сообщение, вы выполните это действие и вернете этот формат в результате.
В ОСТАЛЬНЫХ, если бы я хотел, чтобы создать новый профиль, я бы использовать глагол POST
с телом JSON или HTTP-сервера переменных, описывающих мой профиль в URL /profile
POST
должен вернуться на стороне сервера генерируется идентификатор, используя код состояния 201 CREATED
и заголовок Location: *new_profile_id*
(например, 12345)
затем я могу выполнять обновления, изменяющие состояние /profile/12345
с использованием HTTP глагола POST
, скажем, изменить свой адрес электронной addresss или номер телефона. Очевидно, изменение состояния удаленного объекта.
GET
возвратит текущее состояние /profile/12345
PUT
обычно используется для клиентской стороны генерируется ID
DELETE
, очевидный
HEAD
, получает статус без возвращения тела.
С REST он должен быть самодокументирован с помощью хорошо продуманного API и, следовательно, более прост в использовании.
This is a great article НА ОТДЫХ. Это действительно помогает мне это понять.
Я бы сказал, что это гипермедиа-ограничение REST, более того, чем унифицированное ограничение интерфейса, которое устраняет необходимость в WSDL. –
Где именно находится "profile"? Как вы предоставляете помощь, если вместо одного у вас есть десятки? Все остальное обслуживание там основано на рукописных документах и написанных вручную API, которые являются трудоемкими и подверженными ошибкам. –
Я согласен с @EricGrange - пожалуйста, не могли бы вы объяснить, КАК вы знаете, какие сущности вы можете выполнять CRUD (L) операции ON ... если кто-то ничего не записывает? – BlueChippy
Язык описания веб-приложений (WADL) - это словарь XML, используемый для описания веб-сервисов RESTful.
Как и в случае с WSDL, общий клиент может загружать файл WADL и быть немедленно оборудован для доступа к полной функциональности соответствующей веб-службы.
Поскольку службы RESTful имеют более простые интерфейсы, WADL не так необходим для этих служб, поскольку WSDL относится к SOAP-сервисам RPC.
Существует RSDL (язык описания обслуживания), который эквивалентен WSDL. Нижеприведенный URL описывает свою практику http://en.wikipedia.org/wiki/HATEOAS и http://en.wikipedia.org/wiki/RSDL. Проблема в том, что у нас есть много инструментов для генерации кода из wsdl в java или наоборот. Но я не нашел инструмента для генерации кода из RSDL.
RSDL нацелен на покой, как гипермедиа, другими словами, он имеет больше информации, чем дескриптор службы, такой как WSDL или WADL. Например, в нем есть информация о навигации, например гипертекст и гиперссылки.
Например, с учетом текущего ресурса у вас есть набор ссылок os на другие связанные ресурсы.
Однако я не нашел клиентов по отдыху, которые поддерживают этот формат или Rest Server Solutions, с возможностью автоматического его создания.
Я думаю, что есть большой путь для заключения об этом. Смотрите длинную историю HTML и W3C vs Browsers LOL.
Для получения более подробной информации об отдыхе, как гипермедиа посмотреть его: http://en.wikipedia.org/wiki/HATEOAS
Примечание: Рой Филдинг критикует эти тенденции в Rest Apis без hypermidia подхода: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Мой Вывод: Теперь дни, WADL является более распространенным является то, что системы отдыха и интеграции, такие как Camel CXF, уже поддерживают WADL (генерировать и потреблять), поскольку он похож на WSDL, поэтому наиболее легко понять в этом процессе миграции (SOAP to REST).
Давайте посмотрим на следующие главы;)
WSDL 2.0 спецификации добавлена поддержка веб-служб REST тоже. Лучший сценарий обоих миров. Проблема в том, что WSDL 2.0 не поддерживается большинством инструментов. WSDL 2.0 рекомендуется W3C, WSDL1.1 не рекомендуется W3C, но широко поддерживается инструментами и разработчиками. Ref: http://www.ibm.com/developerworks/library/ws-restwsdl/
Не всегда полезно программно привязать к определению и создать прокси-классы, а не вручную кодирования?
полностью согласен, поэтому я лично использовал Swagger.io
Форс является мощным открытым исходным кодом при поддержке большого экосистему инструментов, помогающих спроектировать, построить, документ, и потреблять API RESTful.
Поэтому в основном я использую Swagger, чтобы описать свои модели, конечные точки и т.д., а потом использовать другие инструменты, такие как swagger-codegen для создания классов прокси вместо того, чтобы вручную кодирования его.
См. Также: RAML
- 1. Android-RESTful Services
- 2. Вызов RestFul Services
- 3. Padarn Opennetcf RESTful Services
- 4. Spring Framework RESTful services
- 5. Restful web services
- 6. Обращение Restful services
- 7. restful web services eclipse
- 8. RESTful web services
- 9. RESTful services on AEM
- 10. Akka и RESTful Services
- 11. RESTful Services Samples Generation
- 12. Перетаскивание RESTful services
- 13. Java Jersey RESTful services
- 14. Restful Web Services generate rsdl document
- 15. ColdFusion Web Services wsdl elements
- 16. Зачем нужен репозиторий RESTful Web Services?
- 17. Тест RESTful Services с RestTemplate
- 18. Проект RESTful services - услуги singleton?
- 19. RESTful Web Services или SOAP
- 20. RESTful Web Services Publishing API
- 21. url design for RESTful services
- 22. ColdFusion restful web services URI
- 23. Headerparam in Restful web services
- 24. DDOS Attacks - Restful Web Services
- 25. WCF RESTful services grounding 101
- 26. RESTful Web Services for Flex
- 27. Единичное тестирование джерси Restful Services
- 28. Java Restful Services - без JaxB
- 29. curl POST to RESTful services
- 30. Веб-сервис Spring RESTful - Как получить WSDL?
У меня такой же вопрос. По-видимому, с точки зрения клиентов, услуги, обслуживаемые клиентами, гораздо сложнее использовать услугу WSDL. –
Мне кажется, что если вы разоблачаете что-то простое, тогда вам не нужны WADL или WSDL. Но если вы разоблачаете нечто сложное, как SAP ... Я не могу понять, что у меня нет какого-то отражения и пространства имен, чтобы справиться с множеством функциональности. – Brain2000
Не может ли метод HTTP OPTIONS рассматриваться как «эквивалентный», поскольку он должен предоставлять информацию о доступных методах и параметрах, необходимых для любых возможных действий? – Dim13i