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.
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
It seems you are really doing much with Views so I think Web API would be more concise solution at this point.
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.
Related
I created web service in visual studio 2010 three years back. I use this Web service in my winform project for performing some online functions. Now I want to create web service in visual studio 2013. Here I see web api instead of traditional web service. So my question is that what is the difference between traditional web service and Web api? And can I achieve the same thing in web api which I do in traditional web service?
Web Service in ASP.NET
A Web Service is programmable application logic accessible via standard Web protocols. One of these Web protocols is the Simple Object Access Protocol (SOAP). SOAP is a W3C submitted note (as of May 2000) that uses standards based technologies (XML for data description and HTTP for transport) to encode and transmit application data.
Consumers of a Web Service do not need to know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages (HTTP and XML).
WCF Service
Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data.
In what scenarios must WCF be used
A secure service to process business transactions.
A service that supplies current data to others, such as a traffic report or other monitoring service.
A chat service that allows two people to communicate or exchange data in real time.
A dashboard application that polls one or more services for data and presents it in a logical presentation.
Exposing a workflow implemented using Windows Workflow Foundation as a WCF service.
A Silverlight application to poll a service for the latest data
feeds.
Features of WCF
Service Orientation.
Interoperability.
Multiple Message Patterns.
Service Metadata.
Data Contracts.
Security.
Multiple Transports and Encodings.
Reliable and Queued Messages.
Durable Messages.
Transactions.
AJAX and REST Support.
Extensibility.
Difference between Web Service in ASP.NET & WCF Service
WCF is a replacement for all earlier web service technologies from Microsoft. It also does a lot more than what is traditionally considered as "web services".
WCF "web services" are part of a much broader spectrum of remote communication enabled through WCF. You will get a much higher degree of flexibility and portability doing things in WCF than through traditional ASMX because WCF is designed, from the ground up, to summarize all of the different distributed programming infrastructures offered by Microsoft. An endpoint in WCF can be communicated with just as easily over SOAP/XML as it can over TCP/binary and to change this medium is simply a configuration file mod. In theory, this reduces the amount of new code needed when porting or changing business needs, targets, etc.
ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Basically you can see WCF as trying to logically group together all the different ways of getting two apps to communicate in the world of Microsoft; ASMX was just one of these many ways and so is now grouped under the WCF umbrella of capabilities.
Web Services can be accessed only over HTTP & it works in stateless environment, where WCF is flexible because its services can be hosted in different types of applications. Common scenarios for hosting WCF services are IIS,WAS, Self-hosting, Managed Windows Service.
The major difference is that Web Services Use XmlSerializer. But WCF Uses DataContractSerializer which is better in Performance as compared to XmlSerializer.
Key issues with XmlSerializer to serialize .NET types to XML
Only Public fields or Properties of .NET types can be translated into XML.
Only the classes which implement IEnumerable interface.
Classes that implement the IDictionary interface, such as Hash table cannot be serialized.
Important difference between DataContractSerializer and XMLSerializer
A practical benefit of the design of the DataContractSerializer is better performance over Xmlserializer.
XML Serialization does not indicate which fields or properties of the type are serialized into XML whereas DataCotractSerializer.
Explicitly shows the which fields or properties are serialized into XML.
The DataContractSerializer can translate the HashTable into XML.
http://www.codeproject.com/Articles/139787/What-s-the-Difference-between-WCF-and-Web-Services
I have worked with both technologies yet I’m about to build a new backbone services layer and thinking about WCF vs Web-Api.
The idea is to create a layer of services that will be consumed by both internal .NET components and by front applications.
The following are issues are not relevant to this case:
TCP, UDP
Proxy generator
WS-* standards like Reliable Messaging, Transactions
I'm considering about 2 approaches:
Web-api for app front application above n-tier WCF services
Web-api for app front and for a flexible services layer, thus avoiding HTTP hop between services
Our system is financial oriented, some services will operate as data services using the using some kind of OData and some will perform complex financial transaction (using complex types).
I've read about the new stuff that was recently added to Web-Api 2 and it seems to be a leading platform. I've Googled a lot about pros and cons and that WCF is still alive (or frozen).
A few of the relevant references:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
http://msdn.microsoft.com/en-us/library/jj823172.aspx
Under the assumption that all the services are on the same LAN and this is targeted to enterprise system, what would you recommend and why?
Here's the question... Do you need transport layer flexibility or are you fine with them being http(s) only services? If the services are HTTP-only and (as you say) you don't care about proxy gen and WS-* then I can't for the life of me think of a reason why you'd use WCF.
The programming model for REST / plain old http(s) is just so much leaner, the MVC "style" much more natural and not to mention that WCF can just get really complex really fast, makes me think that I would need a really good reason to choose WCF in 2013...
Not to throw a spanner into the works, but have you considered Service Stack:
https://servicestack.net/download
That's what I'd be using... (btw I'm not affiliated with them in any way / shape / form).
If you need multiple endpoints/transport protocols, or the ability for other applications to consume your services in .NET and work with them as you would any other referenced library (via web reference and a SOAP endpoint) the WCF should be your choice.
If you're looking for something lightweight and convention-based and/or you're looking to create a RESTful API, and HTTP(S) is an adequate transport, then Web API is the way to go. In this case, if you want the strong typing that you'd get with a SOAP web reference you'd probably be wise to write a reusable library that acts as middleware for consuming the services and providing data.
I've the good fortune of being able to kick off a new project with the tooling of my choice, which is ServiceStack. The Architecture is very solid and the product was out before web api was even a glimmer in someones eyes. That being said, it would be a great plus, if I could also recreate some legacy SOAP endpoints and route then through this service instead of have two apis running at the same time. Is there a preferred way to do such a thing?
Thank you,
Stephen
Not sure about what migrating legacy SOAP endpoints over to ServiceStack entails.
But ServiceStack's SOAP support works like all the other REST, Web and MQ endpoints and Content-Types, where it automatically exposes SOAP endpoints around your services Request and Response DTOs allowing it to be called via SOAP 1.1/1.2.
The inherent limitation in SOAP means that only Services that support POST (i.e. Post() or Any()) are available to be called by SOAP. For services that use any other HTTP/REST Verbs it will be disabled in the metadata pages as seen in the SocialBootstrap API metdata pages. See SOAP Limitations for other things you should be weary of.
The metadata pages also contain links to your services WSDLs and XSDs, e.g:
/api/soap11/
/api/soap12
XSDs: /api/metadata?xsd=1
If you want to host legacy .asmx SOAP services in the same application than you should host ServiceStack on a /custompath so you're able to use it with any other ASP.NET Web, MVC or other web services frameowrk.
I'm about to start a project where we have a back-end service to do long-winded processing so that our ASP.NET website is free to do quicker requests. As a result I have been reading up on services such as WCF and Web API to get a feel for what they do. Since this back-end service will actually be made up of several services communicating to each other and will not be publicly available to our customers, it seems that WCF is the ideal technology for this kind of scenario.
But after doing a lot of research I am still confused as to the benefits and differences between WCF and Web API. In general it seems that:
If you want a public and/or a RESTful API then Web API is best
WCF can support far more transports than just HTTP so you can have far more control over them
Web API development seems easier than WCF due to the additional features/complexity of WCF
But perhaps my question boils down to the following:
Why would a REST service be more beneficial anyway? Would a full blown WCF service ever be a good idea for a public API? Or is there anything that a WCF service could provide that Web API cannot?
Conversely, if I have a number of internal services that need to communicate with each other and would be happy to just use HTTP as the transport, does Web API suddenly become a viable option?
I answered a couple of related questions:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Should it be a WebAPI or asmx
As an additional resource, I would like to recommend you to read:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
If you want to learn more about REST, check this Martin Fowler article
Summaring up:
As far as I know, both technologies are being developed by the same team in Microsoft, WCF won't be discontinued, it will still be an option (for example, if you want to increase the performance of your services, you could expose them through TCP or Named Pipes). The future is clearly Web API
WCF is built to work with SOAP
Web API is built to work with HTTP
In order to take the correct choice:
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.
One combersome bit of WCF is the need to generate new client proxys when input and/or output models change in the service. REST services don't require proxys, the client simply changes the query string sent or changes to parse and/or use the different output.
I found the default JSON serializers in .Net to be a bit slow, I implemented http://json.codeplex.com/ to do the inbound and output serialzation.
WCF services are not that complex, REST services can be equally challenging as you're working within the confines of HTTP.
ASP.net Web API is all about HTTP and REST based GET,POST,PUT,DELETE with well know ASP.net MVC style of programming and JSON returnable; web API is for all the light weight process and pure HTTP based components. For one to go ahead with WCF even for simple or simplest single web service it will bring all the extra baggage. For light weight simple service for ajax or dynamic calls always WebApi just solves the need. This neatly complements or helps in parallel to the ASP.net MVC.
Check out the podcast : Hanselminutes Podcast 264 - This is not your father's WCF - All about the WebAPI with Glenn Block by Scott Hanselman for more information.
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?
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.
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).