Wie die Umsetzung SOAP-Dienst auf WebAPI

Wir haben einen server, der verschiedene Arten von api (für benutzerdefinierte XML-API auf Basis der httplistener, SOAP-API, basierend auf WCF und REST-API basiert auf dem WEB-API). Wir wollen bewegen sich alle API, um WEB-API (es gibt viele Gründe) und es sollte abwärts kompatibel.

Einer der Gründe zur Unterstützung der url-Struktur: Dienstleistungen/service1. Dienstleistungen/service2. Und in diesem Fall sollte es an einem port. Es ist eine intranet Anwendung, die verteilt sich auf mehrere Kunden und es sollte einfach zu implementieren, zu installieren. So, wir kann nicht haben eine lange Konfiguration auf Kundenseite (proxing und otherts).

Gibt es einfach Weg für die Umsetzung SOAP-Dienst auf der web-api? Auf den ersten Blick sollte leicht sein, Wege zu analysieren, httprequest, um typisierte soap-Umschlag (basierend auf Vertrag existierte) und serialisieren einer Antwort. Natürlich gibt es viele Aktionen und Datentypen im Vertrag.

PS: ich will nicht schauen Sie in servicestack:)

Update:

Das problem, das ich oben beschrieben behoben werden kann, indem proxing http-Anfrage soap-service (Es kann nur mit "basichttpbinding" ohne Sicherheit. Wenn der WCF-Dienst benötigen NTLM Authentifizierung funktioniert es nicht):

[HttpPost]
public async Task<IHttpActionResult> SoapAction()
{
    var httpClient = new HttpClient();

    var httpRequestMessage = new HttpRequestMessage(HttpMethod.Post, "http://localhost:8111/soap")
    {
        Content = this.Request.Content
    };

    foreach (var header in this.Request.Headers)
    {
        httpRequestMessage.Headers.Add(header.Key, header.Value);
    }

    var responseMessage= await httpClient.SendAsync(httpRequestMessage).ConfigureAwait(false);

    return ResponseMessage(responseMessage);
}

Aber ich will immer noch wissen, gibt es irgendwelche SOAP-parser in C#, weil mein server unterstützt die NTLM-Authentifizierung.

InformationsquelleAutor Andection | 2016-11-30
  1. 3

    Ich würde nicht empfehlen, mischen Sie die Technologien. Haben ein Projekt für SOAP-Apis und ein anderes für die WebApi, teilen die gleiche Logik.

    Haben Sie dann eine url für den soap -, die andere für die webapi.

    Bearbeiten:
    Ich würde nicht den SOAP-Parser überhaupt. Das war die macht der WCF und würde weiterhin zu verwenden.

    Seit proxing ist keine option (Was getan werden könnte im web.config und leicht eingesetzt), würde ich erstellen Sie eine WebAPI-Endpunkt, umleiten würde, um SOAP-API.

    [HttpGet]
public IHttpActionResult Service1()
{
   return Redirect("http://service.com/soap/services/service1");
}

    Später, wenn die Migration der Logik, verwenden Sie den Dienst selbst.

    [HttpGet]
public IHttpActionResult Service1()
{
   var result = new ServiceLogin1().Execute();
   if(result == null)
   {
          return StatusCode(HttpStatusCode.NoContent);
   }
   else
   {
          return Ok();
   }
}
    • Wir wollen gleichen url-Struktur: Dienstleistungen/service1. Dienstleistungen/service2. Und in diesem Fall sollte es an einem port. Es ist eine intranet Anwendung, die verteilt sich auf mehrere Kunden und es sollte einfach zu implementieren, zu installieren. So, wir kann nicht haben eine lange Konfiguration auf Kundenseite (proxing und otherts). Wir erstellen innen-proxy -, natürlich. Aber normale soap-parser sieht besser aus. PS: ich kann nicht Bearbeiten Sie den Kommentar.
    • Alle API ' s, natürlich, haben die gleiche Logik...
    • Update-die Antwort. Ich bin wirklich kein fan der Parser. Für mich ist das doppelte Arbeit und ärger.
    • Danke für redirect-Vorschlag. Aber wie es aussieht, funktioniert nicht. client empfängt Bad Request: System.ServiceModel.ProtocolException: remote-server hat eine unerwartete Antwort zurückgegeben: (400) Bad Request. ---> System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (400) Bad Request. System.Net.HttpWebRequest.GetResponse() bei System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
    • Ich dachte über proxing nach deiner Antwort, vielen Dank
    InformationsquelleAutor jaimetotal
  2. 3

    Ich denke, das ist hier schon beantwortet wurden ASP.NET WebAPI + Seife

    Wenn das, was Sie fordern, wie erstellen von REST-Wrapper-Aufruf der SOAP-Implementierungen dann Bibliothek ist wie ServiceStack, dies für Sie tun, aber wenn Sie möchten es selbst tun, mit WebApi es ist ziemlich einfach. Stellen Sie einfach ein separates Projekt, dass Ihr SOAP-service Referenzen in den es eingehüllt in eine Art von Abstraktion und dann darauf verweisen, dass in Ihrem WebApi-Projekt, und rufen Sie in Ihr REST-Endpunkte.

    Wenn das, was Sie Fragen, ist, wie host die SOAP-Schnittstellen in WebApi ich denke, dass Sie einfach mehr für sich selbst arbeiten. Der WCF-Gerüst, das von MS zur Verfügung gestellt hat. WebApi für REST-Dienste mit WCF für SEIFE.

    • Erste option (ich udated es in meiner Frage) ist nicht gerecht zu mir. Ich sollte die Unterstützung der NTLM-Authentifizierung erfordern eine direkte TCP/IP-Verbindung.
    InformationsquelleAutor Michael Dennis
Schreibe einen Kommentar