Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should it be a WebAPI or asmx

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 (currentUserID, DataType, ActionName). It returns them and an XML string of the data they have requested. The API is consumed by client-side JavaScript code. The other API receives an XML string and uses that on the server side to perform actions on the database.

like image 359
Matt Avatar asked Jul 25 '12 05:07

Matt


People also ask

Is Asmx obsolete?

If you can work with WCF then yes the ASMX services are obsolete because the WCF can fully replace them with more performance and flexibility (multiple binding), functionality.

Should I use Web API or MVC?

Web API can be used for generating HTTP services that replies data alone, but MVC would be suitable for developing web applications that replies as both, views and data. Web API looks at Accept Header of the request who returning the data in various formats, so it can return in various formats, like XML, JSON etc.

When should we choose WCF and Web API?

Use WCF to create reliable, secure web services that are accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services.

Is Asmx SOAP or REST?

ASMX provides the ability to build web services that send messages using the Simple Object Access Protocol (SOAP).


1 Answers

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:

http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec

like image 131
Jupaol Avatar answered Oct 15 '22 03:10

Jupaol