2016-05-12 7 views
1

Nehmen wir an, ich habe einen WCF-Dienst Service1.svc, der GetData(value) enthält.Convert Web API rückwärtskompatibel mit WCF

[ServiceContract] 
public interface IService1 
{ 
    [OperationContract] 
    string GetData(int value); 
} 

public class Service1 : IService1 
{ 
    public string GetData(int value) 
    { 
     return string.Format("You entered: {0}", value); 
    } 
} 

ich auch einen Client, der bereits die Proxy-auto generiert, diesen Dienst zu verbrauchen, so etwas wie diese:

using (var client = new ServiceReference1.Service1Client()) 
{ 
    var result = client.GetData(1); 
    //Assert.AreEqual("You entered: 1", result); 
} 

Nun entfernte ich, dass WCF-Dienst und ersetzt sie durch einen neuen Web-API Service, etwa wie folgt:

[RoutePrefix("Service1.svc")] 
public class DataController : ApiController 
{ 
    [HttpGet] 
    [Route("GetData")] 
    public string GetDataOld(int value) 
    { 
     return string.Format("You entered: {0}", value); 
    } 
} 

Also, wenn ich versuche Service1Client() den Client zu verwenden, es funktioniert nicht mehr. Ich bin mir ziemlich sicher, dass das möglich ist, aber was muss ich tun, um dieses Ziel zu erreichen?

aktualisiert 05/23/2016

Da dies nicht möglich ist, habe ich beschlossen, einen Proxy zu erstellen, so dass der Client (s) den neuen REST-konformen Web-API leicht umsetzen kann.

+3

Es hängt alles von der verwendeten Bindung ab. Wenn es eine WebHttpBinding war, dann war der Transport REST; Wenn nicht, müssen Sie den Client neu implementieren oder einen Übersetzungsproxy einführen, was nicht trivial ist. – CodeCaster

Antwort

-1

WebApi ist entworfen, um REST Endpunkte zu sein, so ist der Weg von var client = new ServiceReference1.Service1Client() gegen das Konzept.

Eher sollten Sie versuchen, über die URL darauf zuzugreifen, für Ihr Beispiel wird es so etwas wie ~\Service1.svc\GetData\1 sein. Überprüfen Sie auch Ihre route Konfiguration, um sicher zu gehen.

-1

Ihr ServiceReference1.Service1Client() steht in direktem Zusammenhang mit WCF. Sie können es nicht für die Interaktion mit WebApi-Endpunkten verwenden.

Wenn Sie einen Client benötigen, der mit Ihren WebApi-Endpunkten interagiert, müssen Sie selbst einen Wrapper-Client schreiben. RestSharp ist meine Bibliothek der Wahl für so etwas. Beispiel:

var client = new RestClient("http://localhost:8000"); 
int value = 12345; 

var request = new RestRequest($"Service1.svc/GetData/{value}", Method.GET); 
IRestResponse response = client.Execute(request); 
var content = response.Content; // returns "You entered: 12345" 

(ungetestet)

0

Dies ist möglich, und wir tun noch etwas ähnlich - wir unsere WCF/SOAP-Service-Endpunkte mit WebAPI/JSON-Endpunkte ersetzt, ohne die Client-Proxys zu ändern.

Um dies zu tun, müssen Sie die WebHttpBinding verwenden und einige weitere Attribute zu Ihrem Service-Interface so hinzufügen, dass der Proxy generiert die richtigen Anrufe:

[ServiceContract] 
public interface IService1 
{ 
    [OperationContract] 
    [WebGet] 
    string GetData(int value); 

    [OperationContract] 
    [WebInvoke(Method="POST", RequestFormat = WebMessageFormat.Json)] 
    void PostData(MyDataType data); 
} 

Dies wird die Proxy-Anwendung HTTP-Anrufe tätigen, anstatt SOAP-Anrufe, um auf Ihren Service zuzugreifen. Wie Sie sehen, funktioniert dies sowohl für GET- als auch für POST-Anfragen und serialisiert Ihre Daten automatisch als JSON (oder XML, falls Sie dies bevorzugen).

Es gibt mehr Möglichkeiten, um customize es - wie die UriTemplate Eigenschaft mit komplexeren HTTP Routen zu spezifizieren (oder zwei Methoden, GetData und PostData, die beide auf denselben Weg und unterscheiden sich nur durch verb, die RESTful Art und Weise). Und es gibt auch Vorbehalte - von dem, was ich sehen konnte, können Sie nur Strings zu GET-Anfragen, nicht ints übergeben. Aber alles in allem funktioniert es ganz gut.

Hätten wir uns entschieden, mit WCF-Proxies zu arbeiten, die WebAPI-Endpunkten zugeordnet sind, wenn wir das Projekt mit WebAPI/REST gestartet haben? Wahrscheinlich nicht.Dies ermöglichte uns jedoch, Back-Ends mit relativ wenig Front-Code-Änderungen zu wechseln.