我们为WCF服务使用SOAP和REST端点。 ASP.NET Web API对我们意味着什么？

Question

On our services, we configure several endpoints, allowing us to publish the same interfaces to SOAP 1.1 and 1.2 clients and HTTP clients consuming either XML or JSON. Now that the WCF REST team has been merged into the ASP.NET team to create the Web API stuff, what will this mean for us in the future? Will it still be supported to expose WCF interfaces as XML/JSON services? Should we move the REST endpoints to the Web API framework? Will this be the last shift of the MS REST stack?

Answer 1

Good question. I don't work for Microsoft and I don't have any inside information but my understanding is that WCF will be able to expose XML and JSON forever. In fact if you are merely exposing JSON or XML endpoints you are not doing REST. The real question is do you use the HTTP verbs (DELETE, PUT, POST, GET) as part of your API or you are simply exposing methods that are equivalent to your SOAP methods. If you are using the HTTP verbs it may be a good long-term strategy to migrate the REST part to WebAPI. If you are not then you can happily use WCF (go ahead tell your cusomers you are using REST for marketing reasons, to marketing people it's just a buzzword anyway).

If you are using the HTTP verbs it is not that hard to have both WCF and WebAPI. All you need to do is remove all logic from the service itself and expose it as a business layer methods. Then both kids of services can use these methods, call them in the appropriate way and shape the results.

Answer 2

To answer this, you need to have a little history on the ASP.NET Web API.

Initially the ASP.NET Web API it was the WCF Web API , a project on Codeplex extending WCF to make it easier to support a REST-style service. WCF was entirely built on SOAP as its core messaging type, so using HTTP as anything other than a transport-layer protocol required a different approach, with a different set of attributes and generally didn't mesh well with the rest of the framework.

The WCF Web API was extending the WCF framework in all the ways required to support HTTP as an application-level transport mechanism. It was introducing request routing based on the resource URI, dynamic formatting according to the Accept headers and the other things which were previously missing from WCF.

However, it became clear during its development that these technologies already existed within .NET, in the MVC stack. Thus, the decision was made that rather than having two competing sets of technologies, they move the work over to the ASP.NET MVC team, and the ASP.NET Web API was born.

---

If you are doing a REST-style service, the ASP.NET Web API is much better suited to your needs than the WCF framework. The WCF team will not be progressing their support for the REST-style architecture; these features of the WCF framework are effectively subsumed by the Web API, where it finds a much more natural fit .

Should you re-write your services to use the new Web API? Well, the REST features of WCF aren't going to suddenly stop working. You should only consider the move if it gives you some features you're after (like dynamic content-format selection), or if you're looking to continually develop your API (as the Web API is significantly easier to use than WCF).