asp.net convert Should it be a WebAPI or asmx
convert asmx to web api (3)
Should I leverage an ASMX service or the ASP.NET Web API for my two simple API's?
I want to create two simple APIs in my ASP.NET MVC project. One takes in 3 parameters (
I just answered a related question:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Basically, the frameworks provided by Microsoft to develop Web Services are:
ASMX. XML Services based on SOAP.
WCF. Web services based on SOAP. These services were the evolution of the traditional ASMX services and basically they focused to separate the service itself from the transport protocol. That's why you can expose the same service using several endpoints and therefore several protocols (TCP, HTTP, Named Pipes, MSMQ, HTTPS). This flexibility came with the configuration problem. One of the main complaints in the community about the WCF is the tedious and extensive configuration
WEB API. Based on HTTP not in SOAP. This new API is a new framework to create services. The main difference with the other two predecesors, is the fact that it's based on HTTP and not on SOAP, therefore you can use several HTTP features like:
- It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
- use of verbs to define the actions (POST, PUT, DELETE..)
- it contains a body that can be used to send any kind of content
- It uses URIs for identifying both information paths (resources) and actions
WEB API is focused on writing services to expose them via HTTP (only on HTTP at the moment). If you want to expose your service using another protocol, then you should consider using WCF.
WEB API is based on MVC (if you want to know the reasons why it's based on MVC, they are simple)
Another goal of the WCF Web APIs was to incorporate known concepts that would help developers to overcome some of the drawbacks they faced with WCF, such as huge configurations, overuse of attributes, and the WCF infrastructure that did not support testing well. Thus the Web APIs used IoC, enabled convention-over-configuration, and tried to offer simpler configuration environment.
ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services.
Take the following points into consideration to choose between WCF or WEB API
- If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
- If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
- If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
- If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
For a more detailed comparison:
If possible, I would use an Web Api Controller in mvc4. You can return an generic ienumerable list or model and it will automatically output the data to whatever format is requested such as xml or json. Its pretty amazing.
It seems you are really doing much with Views so I think Web API would be more concise solution at this point.