Это немного другой сценарий, чем то, о чем ОП, вероятно, намеревался спросить , но это более широкое толкование "как создать что-то вроде 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, чтобы получить конкретные значения, которые мне нужны. Это избавило меня от попыток перепроектировать сериализуемый POCO XML для соответствия определенной структуре запроса WSDL.
Создание ответа SOAP
Вы можете использовать такие инструменты, как Svcutil.exe с Visual Studio, для генерации XML-сериализуемых POCO. Поскольку мы не используем WCF, вы не будете использовать полный контракт на обслуживание, а просто вытяните POCO-объекты класса C #, чтобы вы могли заполнить их данными и сериализовать их в 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, и вы должны внедрить клиент для его использования, что, как правило, намного проще.