Интерфейс веб-API ASP.NET(WSDL)

Ответ 1

Что касается того, хорошо ли это выглядит, это мнение, поэтому попробуйте и посмотрите (мне это нравится лично)

Что касается WDSL, веб-API - это API RESTful, а не SOAP, поэтому поддержка WSDL не поддерживается, WCF имеет поддержку REST и SOAP, поэтому это может быть лучшим выбором, если вам нужен SOAP-сервис и WSDL, последний блог ScottGu на API довольно интересен и имеет ссылки на учебные пособия (вопрос о генерации WSDL также отвечает в комментариях)

http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx

Ответ 2

В WebApi нет поддержки SOAP или WSDL. Если вам нравится WebApi, вам понравится ServiceStack, у которого есть поддержка как REST, так и SOAP. Вы можете генерировать WSDL со стеком сервисов даже для служб REST.

Ответ 3

Это немного другой сценарий, чем то, о чем OP вероятно предназначено, но более широкая интерпретация "как создать что-то вроде WSDL для моего API, например, как служба WCF?"

У меня была ситуация, когда мы не смогли открыть службу WCF, и единственным вариантом был WebAPI. Однако сторона, использующая API, поддерживала только SOAP/WSDL и имела предопределенный WSDL, для чего им требовался интегратор для размещения и соответствия.

Обслуживание файла WSDL

Одно действие WebAPI служило WSDL файлу, который был только статическим файлом WSDL. Этот подход не поддерживает запросы к частям WSDL. Таким образом, клиент должен использовать URL-запрос yourdomain.com/SomeRoot/SomeApiPath?wsdl, любые параметры строки запроса после этого будут проигнорированы и будет обслуживаться полный WSDL. Параметр [FromUri] string wsdl гарантирует, что это действие выбрано для URL с ?wsdl в нем, но в нем не будет никакого значения.

public IHttpActionResult SomeApiPath([FromUri] string wsdl)
    {
        System.IO.FileStream wsdlFileStream = System.IO.File.OpenRead(System.Web.HttpContext.Current.Server.MapPath("~/Content/SomeThing.wsdl"));
        var response = new HttpResponseMessage(HttpStatusCode.OK);
        response.Content = new StreamContent(wsdlFileStream);
        response.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("text/xml");
        return ResponseMessage(response);
    }

Это означает, что ваши методы API Action должны обрабатывать и отвечать на запросы XML SOAP.

Обработка запроса SOAP

Хотя WebAPI может связывать параметры с XML-запросами, я решил не иметь параметров в своих действиях, и вместо этого я использовал Request.Content.ReadAsStringAsync() в каждом действии, чтобы получить тело запроса (это XML-запрос SOAP), а затем проанализировал его с помощью XML для LINQ, чтобы получить конкретные значения, которые мне нужны. Это избавило меня от попыток реконструировать сериализуемый XML-код POCO для соответствия структуре запросов WSDL.

Создание ответа SOAP

Вы можете использовать такие инструменты, как Svcutil.exe, с Visual Studio для генерации XML-сериализуемых POCO. Поскольку мы не используем WCF, вы не будете использовать полный контракт на обслуживание, а просто вытащите POCOs класса С#, чтобы вы могли заполнить их данными и сериализовать их в XML для создания ответа. Однако создание SOAP-конвертов, содержащих все правильные ссылки на пространство имен, является чрезвычайно сложным. Я взломал в некоторых местах и ​​фактически использовал конкатенацию строк вместо сериализации XML. Сериализовать строку XML и вернуть ее в ответ на StringContent:

return ResponseMessage(
       new HttpResponseMessage(HttpStatusCode.OK)
       {
           Content = new StringContent(soapResponseBody, System.Text.Encoding.UTF8, "text/xml")
       });

Примечание. Даже исключения должны быть пойманы и преобразованы в XML как ошибка SOAP внутри конверта SOAP.

Все вышеперечисленные ужасные обходные пути являются доказательством того, что если вы абсолютно должны поддерживать SOAP, использование чего-либо, кроме WebAPI, будет намного проще. Мне нравится WebAPI, но когда вам нужно интегрироваться с другой системой который поддерживает только SOAP/WSDL, это, конечно, не инструмент для работы. Я предоставляю вышеописанное описание подхода к решению этой проблемы, если у вас нет другого варианта, но рекомендую использовать инфраструктуру помимо WebAPI с поддержкой SOAP.. У вас наверняка возникнут проблемы с выше, и вам нужно будет иметь большой опыт работы с XML-сериализацией и XML-схемами, чтобы понять, как преодолеть эти проблемы.

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

Ответ 4

ServiceStack - хорошая альтернатива, которая включает встроенную поддержку для SOAP, который автоматически генерирует WSDL, XSD и описания схем из ваших определений услуг, доступных из ваших автоматически генерируемых страниц метаданных.

Добавить ссылку ServiceStack

ServiceStack также предлагает лучшую альтернативу WCF Добавить ссылку на службы, которая может генерировать типизированный API только с URL-адреса, используя Добавить ссылку ServiceStack.

Преимущества перед WCF

• Простой Использует небольшой шаблон T4 для сохранения сгенерированных типов POCO. Обновление так же просто, как повторный запуск шаблона T4
• Универсальный Чистые DTO работают во всех JSON, XML, JSV, MsgPack и ProtoBuf общих клиентах службы.
• Многоразовый Сгенерированный DTO не привязан к какой-либо конечной точке или формату. Значения по умолчанию являются как частичными, так и виртуальными для максимального повторного использования.
• Устойчивые Услуги на основе обмена сообщениями предлагают ряд преимуществ перед службами RPC
• Гибкая Генерация DTO настраивается, сервер и клиенты могут переопределять встроенные значения по умолчанию
• Интегрированные Метаданные Rich Service, аннотированные по DTO, Внутренние службы исключаются при доступе извне