У меня есть информация об ASP Web API.
Это похоже на хороший материал для веб-сервисов, но как создать что-то вроде WSDL для моего API, например службы WCF?
как сторонний компонент может использовать мой сервис? Или мне нужно описать каждый мой метод вручную?
Ответ 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
Ответ 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, и вы должны реализовать клиента, чтобы его использовать, что обычно намного проще.
