ASP.Net Web API vs WCF, which I have to choose in my project

Question

I have read many articles on the Internet so far about the differences between WCF and ASP.Net web API. Unfortunately, I could not come to a clear idea of ​​what would serve my purpose. Most of the articles I read have been emphasized in terms of the design of the two web services. But I'm confused about what works best for my project and why? Here is my brief description of the project.

I need to create a communication channel between two servers (both are written in C #). Servers will exchange messages (specific types of commands). Sometimes messages can only be confirmations, and sometimes messages can contain instructions for performing some calculations. For example, one message can draw something or send SMS, etc. And it is not necessary that the messages include any database transactions. But messages can sometimes send large text files as a payload (about 1-5 MB max.). The fact that I think WCF will certainly do this, but can I do the same with the ASP.net web API. Since so far the whole example that I have seen for ASP.Net web api: they are good for RESTful services that manage some kind of database storage (GET, PUT, DELETE). But in my case, I will need to set up service points that will

do some processing like returning a calculation value, sending and acknowledging messages, etc.

Not just manipulating DB storage.

So what should be the best and easiest way to do this? It should be noted that I did not find a direct example of achieving this using ASP.Net web API.

Answer 1

The question you asked is overly broad or mostly opinion-based, and it's hard to imagine an example of what you asked.

Important points:

• First, if you intend to create a service that will be used on different platforms, go to WCF.
• Secondly, if you are creating an Internet service that will use an external resource , go to the web API.
• The Web API is the best choice if you intend to create a service for low-bandwidth devices or mobile devices to access the client. HTTTP request / response is also more readable than SOAP, as it contains a header, body, etc., which makes it complicated.

Just take a few minutes and read the article below until you get a complete understanding of a few principles.

The source can be found here , here and here .

To choose between WCF or WEB API:

• Choose WCF if you want to create a service that should support specific scenarios such as one-way messaging, message queues, duplex, etc.
• Choose WCF if you want to create a service that can use fast transport channels when available, such as TCP, Named Pipes, or possibly even UDP (in WCF 4.5), and also want to support HTTP when all other transport channels are unavailable .
• Choose a web API if you want to create resource-oriented services over HTTP that can use full HTTP features (e.g., URIs, request / response headers, caching, version control, various content formats).
• Choose a web API if you want to provide your service to a wide range of customers, including browsers, mobile phones, iphone and tablets.

Why choose a web API

• The Web API does not have a tedious and extensive configuration, such as the WCF REST service.
• It is very simple by creating a service using the Web API. Where, as with WCF REST, creating a service is difficult (requires a clear understanding of the configurations).
• The Web API is based only on HTTP and HTTPS and easily defines, expands and consumes in a REST-complete way.
• The Web API is a lightweight architecture and is well suited for devices with limited bandwidth, such as smartphones.

My opinion:

• The easiest way to do this is with a web API (since you have no examples for this)
• The most difficult way (configurations) is WCF (better with WCF, since you have examples)

Hope this gives you a clear idea of ​​what to choose ...

Answer 2

WebAPI is not only good for RESTful web services. You can easily send requests to the WebAPI controller and process it the way you want: computing, sending messages, interacting with CRM, interacting with the database, or something else.

WCF was created to manage SOAP-based web services and brings added complexity. It handles TCP, Mime ...

If you just need to handle HTTP requests, the easiest way is to use WebAPI.

Answer 3

I would suggest a Web API if this is for RESTful services, since WCF was never created to serve Restful, although you can serve where the Web API was created for this.

Answer 4

First of all, RESTful is a stateless and unified interface norm that can be applied to web services. It should not be automatically and only a simple old CRUD service supported by the database.

In the real world, we can hardly say that all web-REST APIs are fully consistent with the norm, in fact they are not in most cases, especially in the stateless part.

For your message-based API, especially if it is bidirectional and event-based, you can use web ports and consider the REST API to expose a single, stateless web interface to create them. And yes, you can use websockets with ASP.NET WebApi there is a lot of tutorial there, even for the new ASP.NET kernel.

Part of the interaction between the services is no different from a regular web browser <=> web service, you just use C # code instead of JS for the client.

I can hardly recommend a WCF that uses SOAP, as it is hardly portable with web standards these days. For example, if you want to use the browser client instead of another ASP.NET service, you will need to make an additional client part of the code to handle the supported functions.

You can use WCF websites , providing almost all the benefits of WCF SOAP.

tl; dr:

• You can mix RESTful and Websockets, it can be better than full REST or full websites.
• It’s a personal preference to use SOAP over websites, but it has a potential technical debt, considering what you want to do later
• The message API between services is not different from the message API between service and browser