We have an ASP.Net C# application that requires some form of a web services implementation for integration with other applications. Currently we have been looking at servicestack and also using an ESB e.g. Mule.
I am trying to figure out the best way to integrate an ESB like Mule into our ASP.Net application.
Do we need to build a web service into our ASP.Net application so that an ESB can integrate with it?
If yes what would be a good approach for selecting a web service type (e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an ASP.Net application and Mule?
Do we need to build a web service into our ASP.Net application so that
an ESB can integrate with it?
Usually it's the other way around. An integration middleware, like Mule, speaks tons of protocols just for the sake of being able to connect to existing systems without changing them.
If yes what would be a good approach for selecting a web service type
(e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an
ASP.Net application and Mule?
If your application has really no pre-existing channel you could use to integrate with (not even a simple web form HTTP POST? really?) and you want to expose an API so an integration middleware can connect to it, pick the architecture/technology that maps to the API style you're creating (REST for a resource oriented API, SOAP for a RPC oriented API).
This sounds backwards. What are you required to integrate with, and what capabilities are you trying to provide?
A web service is decoupled from its implementation, you would choose to use a web service if you're trying to expose your system capabilities in an interoperable way so that it's accessible by a broad range of clients.
What you do within a web service is up to you, i.e. you could then for example connect with your ESB. Nothing is precludes you from doing that. ServiceStack also supports hosting from within an existing ASP.NET (or MVC application) see the Hello World example for different ways of configuring ServiceStack.
REST / RPC has to do with the design of your web services and ServiceStack supports both models. i.e. inherit from RestServiceBase if you want to provide different implementations when the service is invoked with different HTTP Verbs. Inherit ServiceBase if you want the same implementation to be used no matter how it was invoked. This article shows the difference between REST vs RPC/SOAP - and how you can support both in ServiceStack.
So if your exposing a single operation (or want to support SOAP) use ServiceBase, if your exposing a 'Resource' where you want to allow it to be managed using different HTTP Verbs use RestServiceBase.
Related
I heard that rest services are moved from wcf to asp.net web api frame work.
Our web application is built on vs 2010 (asp.Net 3.5) .So still i can use wcf rest services in my web application?
Please suggest some alternatives if it is not possible.
WCF can still be used to build RESTful services1, many services are already built with it and it's not going away. What you heard is that most of the new developments in terms of new functionality in the area by Microsoft will be made in the ASP.NET Web API framework, not in WCF. But as all the services out there can attest, WCF for building web services is still a valid alternative, if it does all you need.
1 The official name is actually "WCF Web HTTP Services"; REST is a well-defined set of constraints which need to be implemented, which would give the service some useful properties. There are some people who argue that people should stop using the term REST for all HTTP-based, non-SOAP services.
ASP.NET Web API seems to lack the service contract / data contract features of WCF web services which would have generated a wsdl that could be used to generate proxy classes. I'm wondering whether Web API is intended for consumption in a service-oriented architecture or if it's meant simply for Ajax consumption.
Web API (as far as I know) does not support WSDL generation. If you absolutely require a WSDL, WCF REST might be an option, though no longer supported.
Service-oriented architecture does not require the use of SOAP or reliance on a WSDL and RESTful services aren't restricted to being useful only for AJAX requests. There are quite a few RESTful web service client libraries available from nuget that makes interacting with these services easier. Though it might not be as simple as using code-gen, creating a library of POCO classes you can share with other C# clients also makes things easier. Hope that helps.
I have been using asp.net MVC for around 1.5 years, am enjoying its capabilities, and have deployed many successful web applications, but I'm currently reading about the asp.net Web API technology. And, I find the following:
I can implement any functionality that I used to implement using MVC; using the new Web API and in a more lightweight approach.
It is easier to develop web services using the Web API comparing the asp.net MVC.
So, will the asp.net Web API take over asp.net MVC in the future, or each technology will have its own area to grow in, or should we consider using both of them in the same web application?
Besides the #jmoerdyk's answer, I would like to point something out:
The key is to understand the goal of each technology:
Web API.
This will be the new API for creating web services, this is an alternative to traditional XML services and WCF services, so it's worth pointing out first the main difference between WEB API and the rest of the Web service frameworks.
The primary difference between Web API and WCF/ASMX services is that it's not based on SOAP it's based on HTTP Therefore you can take advantage of all the 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
That was the main goal of the Web APIs, known back then as the WCF Web APIs: to stop looking at HTTP through the eyes of WCF - as just a transport protocol to pass requests. Rather, it allows us to look at it as the real application-level protocol it is – a rich, interoperable, resource-oriented protocol. The purpose of the Web APIs was to properly use URIs, HTTP headers, and body to create HTTP services for the web, and for everyone else that wished to embrace HTTP as its protocol and lifelong friend.
Take a look to this article for more information: http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
So basically the Web API could actually be compared against WCF or XML Services
If you are wondering what's going to happen with WCF?
So the fact was we had too many options and therefore too much confusion. What were we to do? We merge teams! (Kind of reminds us of the time of LINQ-to-SQL and Entity Framework, WCF and Ado.Net Data Services and other such examples). So the WCF team and the ASP.NET team joined forces and created a new framework focused on the world of REST/Hypermedia/HTTP services for the web world and thus came out the ASP.NET Web APIs.
MVC
Now that you know what's the goal of the Web API, then it should be easier to say why MVC contains additional functionality to render views primarily.
Your concern is based on the fact that WEB API is actually based on MVC, but their goals are different
On the other hand, the 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
No, they don't really do the same thing.
Web API is really only for generating JSON, XML or other text based responses for implementing REST based APIs. MVC can do that as well, but the new Web API appears to make it easier, particularly with the automatic content type negotiation.
What MVC does that Web API is not intended for is generating full or partial HTML pages with Views and such.
So each one has their own purpose in the ASP.Net framework and not likely to surpass the other.
WebAPI and MVC are two different things, but they both work in the same framework. WebAPI is used for restful services. MVC is used for web pages.
You can create restful services in MVC, with a lot more work than in WebAPI. The reverse is not true. You can't create Web pages in WebAPI. Therefore, your question is fundamentally confused.
They are going to be merged in new versions, technically both works similar, but API don't have views attached so delivers better performance
I can't find anything on the implementation of service discovery for the ASP.NET Web API. For a new project I need to make a decision between WCF and Web API. The service element will be consumed by a variety of clients, mobile, client-side JavaScript but also an ASP.NET website.
For the website the convenience of being able to generate a client against a WCF service is obviously a plus. I am not that familiar with RESTful web services but I see that there is Web Application Description Language (WADL). Maybe it is my ignorance but surely it is a good thing to be able to advertise the correct way to consume your service?
My main question: is there anything that generates a WADL or similar for WEB API?
Secondary question: this tool looks like it generates a client based on a WADL, is there anything else that makes life easy keeping a client up to date with a RESTful web service?
There is a considerable amount of work going in there. It is not finished but watch the space.
Having a look here (and newer Yao posts):
http://blogs.msdn.com/b/yaohuang1/archive/2012/05/21/asp-net-web-api-generating-a-web-api-help-page-using-apiexplorer.aspx
Also
http://blogs.msdn.com/b/yaohuang1/archive/2012/06/15/using-apiexplorer-to-export-api-information-to-postman-a-chrome-extension-for-testing-web-apis.aspx
I blogged an approach to generating WADL with ASP.NET Web API here: http://blogs.msdn.com/b/stuartleeks/archive/2014/05/20/teaching-asp-net-web-api-to-wadl.aspx
I have an application that I'm building and for the moment, I built some web services using ASMX. In the end, the application will be deployed on azure. The web services are really simple in that all they do is call a class in the AppCode folder that handles all the work.
Is it going to be better/easier/faster/more performant to move my web services to WCF or to Web API?
Thanks for your suggestions.
PS: I want to add that the web services will need to work in HTTPS. At the moment, they're on HTTP because I'm in development mode.
One-liner: if you have already got a working code and it is risky to move it to another technology stay with the working code.
Depends who is answering.
Web API embraces HTTP and gives you flexibilities not possible with ASMX and WCF. If you care about HTTP, content-negotiation, media types and you need your service to be called from any client (including AJAX) then Web API.
If you need to be able to use WS* security standards (e.g. using X509 certificates, ADFS, etc), possibly change your binding, serve to different clients using different bindings, extensibility, etc use WCF.
If you already have a working code, and all you care about is RPC and your clients are always going to use ASMX then stick with ASMX.
Performance
No benchmark but my gut feeling, in descending order: Web API, ASMX, WCF
Easier
In descending order: ASMX (since you know it), Web API, WCF
Faster development
If you know them all, Web API and ASMX then WCF
PS: it is good to pick up new technologies. The way things are going (and since you are already moving to Azure) it is important to invest on new technologies.