Почему нет поддержки типа WSDL для Web Api?

Поэтому я только начинаю работу с .Net WebApi, и сразу замечаю, что не существует Контракта, определяющего, как API выглядит и должен потребляться (Запрос / Ответ от каждого Действия), обычно это происходит в форме WSDL для WCF / Мыло.

Мне кажется, что это что-то очень ценное и облегчит жизнь пользователям вашего API.

Есть ли причина, по которой ее нет? Есть ли парадигма или принцип программирования, о которых я не знаю? Есть ли способ, которым я мог бы создать?

МЫЛО, ОТДЫХ И НАРОДНОЕ ТВОРЧЕСТВО

Для SOAP необходим документ описания, такой как WSDL, поскольку каждый ресурс может использоваться с различными сообщениями, в протоколе нет определения ограничений на возможные имена / сообщения, которыми вы можете манипулировать ресурсом.

Например, в SOAP ваш веб-сервис, который позволяет клиентам манипулировать пользователем, может представить операцию, которая создает пользователя во многих различных сообщениях, например:

addUser
createUser
insertUser

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

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

POST /Users

И это происходит для каждой операции, которую вы хотите представить с помощью SOAP или REST веб-API.

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

Описание веб-API REST

В области описания веб-API REST я могу привести Swagger . Это не попытка создать WSDL, подобный REST web api, но это хорошая попытка создать открытый стандарт для описания REST web apis.

Swagger - это спецификация и полная реализация инфраструктуры для описания, создания, потребления и визуализации веб-сервисов RESTful.

Я часто использую Swagger и действительно люблю его, главным образом потому, что Swagger UI позволяет создавать приятную живую консоль и документацию для веб-API.

Существует множество реализаций Swagger для большинства языков: C #, Java, Python, Ruby и т. Д.

Если вы используете ASP .NET Web API, есть несколько проектов для автоматической генерации спецификации Swagger, например Swagger.NET

Генерация клиентов для веб-API REST

Поскольку ограничения REST, такие как ограниченный набор глаголов (GET, POST, PUT, DELETE и т. Д.), Не так сложны для создания клиентской библиотеки для REST web api.

Такие проекты, как WebApiProxy, могут легко генерировать клиенты на C # и Javascript.

КОНВЕНЦИИ ДЛЯ ОТДЫХА WEB API

Чтобы облегчить жизнь разработчикам, определите некоторые правила поведения REST нашего веб-интерфейса. Лучшее, что я знаю в этой области, - это очень хорошая книга Apigee - Web Api Design . Электронная книга - это не попытка создать библию или мантру о том, как создать ваш API, а скорее набор соглашений, наблюдаемых в больших веб-API REST, таких как Twitter, Facebook, Linkedin, Google и т. Д.

В двух словах, поскольку SOAP был разработан для самоописания: конечная точка SOAP обычно включает в себя wsdl, который описывает, какие операции он предоставляет, и как выглядят данные (посредством встроенных XSD), которые каждая операция принимает и / или возвращает.
Из-за этой информативности приложение, такое как Visual Studio, может создать для него прокси-сервер веб-службы.

Кроме того, есть несколько расширений SOAP (спецификации WS- *), которые позволяют использовать шифрование или транзакционное поведение с SOAP. Идея заключается в том, что вы можете использовать SOAP в качестве универсального центра для создания веб-сервисов корпоративного уровня.

С другой стороны...

WebAPI предназначен для предоставления услуг REST. Формат связи для REST обычно - JSON или обычный xml - хотя это действительно не имеет значения, это может быть даже простой текст. Службы REST придерживаются совершенно другой философии: они должны быть легковесными, чтобы их можно было легко использовать на клиентских сценариях в составе решения AJAX или на мобильных устройствах.
Таким образом, необходимо свести к минимуму уровень церемонии, включая информативность. Кроме того, даже если вы хотите, большинство форматов связи, используемых в службах REST (таких как JSON), в любом случае не имеют формального описания их содержимого.

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

API-интерфейсы SOAP / WS- * и RESTful не совпадают. Если вы хотите создать API-интерфейсы, поддерживающие SOAP / WS- * WSDL, в стеке Microsoft следует выбрать инструмент WCF, смонтированный с опцией HTTP-привязки (есть опции XML и JSON-привязки, XML - опция поддержки WSDL).

На практике использование WSDL из другого языка реализации или платформы было проблематичным. Уровни безопасности WS- * даже выше.

Мой собственный опыт в основном касался .Net, Node, Java и PHP в этом отношении, и я могу сказать, что когда у вас есть платформы, которые не должны определять детали дочернего типа, или будете использовать «Объект» в качестве определение становится проблематичным, если не сказать больше. Помимо этого, по большей части никто на самом деле не понимает всего SOAP / WS- *, полагаясь на инструменты для его работы. Этот инструмент имеет много накладных расходов, и разные системы работают по-разному.

Вот некоторые из причин, по которым люди пытались использовать более простые реализации. Службы REST (аля Web API) предлагают конечные точки вокруг объектов / состояний. Идея состоит в том, что проще определить набор более простых объектных структур, представленных в формате JSON, и конечные точки для использования с этими структурами, чем пытаться использовать WSDL из чужой среды, которая не работает, а затем попытаться найти и обойти проблему.

Как ни странно, это одна из областей , которые я использовал узел в партии как сервис перевода, просто потому , что она была достаточно гибкой , чтобы принять грязные реализации в качестве клиента, и я мог бы написать несколько простых клиентов с моей адаптированной полезной нагрузки , которая работала лучше. Пример: C # получает текст JSON, который я использую JSON.Net для преобразования в представление объекта, которое, как я определил, действительно работает, когда я не могу использовать импорт WSDL.

На практике это часто случается.

Хотя многие ответы здесь великолепны, я думаю, что ответ НАМНОГО проще: вы ищете неправильную технологию для работы.

Если вы хотите создать SOAP-сервис, вам действительно стоит придерживаться WCF. Это все еще очень мощный фреймворк, Microsoft все еще активно развивает его, мы не сделали никаких заявлений о том, что это произойдет в будущем, и это было сделано с учетом этого. Web API никоим образом не заменяет WCF (хотя, вероятно, он более модный, чем WCF).

Веб-API раньше был частью WCF, но он был перенесен в семейство ASP.NET именно потому, что он не совсем соответствовал другим технологиям WCF. Web API гораздо больше касается использования HTTP в качестве протокола приложения, чем протокола передачи. В веб-API, HTTP-глаголы являются королем, в WCF HTTP просто служит для включения протокола SOAP.

Не вините Web API за то, что он не дает возможности делать определенные вещи, для которых он не был создан.