why is WCF used for intranet services?

Question

I have a new project I am working on. The purpose of the project is to centralize all service calls and provide a single entry point to other services.

Currently, there are about 5 different services that that developers call to get data from different sources internally.

This project would create a single service that other developers in the company can use to call all these 5 different services from a single service.

My question is

should I build the service using Web API (RESTful) or WCF (SOAP based)?

I was suggested by my manager to use a restful approach to creating this service. However, since this service is used internally in the company, i believe WCF would be a more appropriate approach because of WSDL, which you can use to create proxy classes and use objects instead of the client parsing the data returned.

Also, WCF is action driven and Web API is resource driven.

when do you use action driven model and when do you use resource driven?

I would appreciate it if you could provide insight into my situation and help me decide which approach to apply to my project.

Here is what I have so far, but it's still not enough to convince me to use one or the other.

WCF

1. SOAP based services
2. Multiple transport protocol (HTTP, TCP, UDP, etc.)
3. WSDL for creating proxies (generate type safe binder classes/objects)
4. It allows the client to reference the service endpoint just like a class library, which means you're not dealing in XML or JSON in your desktop client. You're working with classes & objects.
5. Has more overhead compared to Web API
6. Internal/Intranet
7. Action-driven model that focuses on what actions a service is a capable of performing
8. WCFExtras+ for documenting service

Web API

1. RESTful services
2. HTTP based (first class citizen)
3. Wide variety of media types (XML, JSON)
4. Light weight
5. No WSDL (often clients end up parsing the data on their own)
6. Public API (wide variety of clients)
7. Resource-driven architecture that exposes endpoints based on objects and not functions
8. Client Interoperability
9. ASP.NET Web API Help Pages using Swagger

UPDATE:

my question is understanding why WCF should be used for intranet application. is it because of WSDL, which creates proxy classes for you automatically and web api, you have to do more work on the client side for parsing the returned xml or json?

Answer 1

One factor to consider is whether the existing service code is "built in" to the existing services. For some years when I created a new service all of the code was part of the WCF service application. That seemed expedient, but it was shortsighted.

It's much better if the application components are built into their own library which can then be exposed by either a WCF service or a Web API. If it's built that way then it's much easier to do one, the other, change your mind, or do both.

I'd lean toward Web API because 1) it's easier for any client to consume it, and 2) everyone seems focused on Web API these days and it's a good area to build experience.

For internally used APIs I have an approach that gives me some of the same benefits as a WCF service.

• The "service" is a separate library from the API. It's just a class library that I can test in isolation from the API.
• I create an interface for the API and its models in a separate library
• I need to create my own client code to test the API, so I create a reusable HTTP client that implements the service interface. Other developers don't need to use it, but if they want to they can add that interface and my existing client. That way instead of writing and testing their own client code they have something that's already done and tested. They also have a separate interface and implementation which is handy for dependency injection.
• It might be overkill, but I make my API implement the same service interface. That way if I modify the interface during the development process (not talking about breaking changes to a published interface) it's really easy to see where I need to update the API, the client, etc.

That provides some convenience for working with internal clients. The downside is that perhaps it's "out of touch" with the best practices for developing a RESTful API.

IMO what's critical is that separation of functionality between the logic and the API or WCF. If you build the API one way and then want to do something different then you can focus on that end of it without having to rewrite or retest the more important parts of the code.