Is an HTTP framework and a web framework the same?
For example:
Sometimes I read that CherryPy is an HTTP framework and sometimes it is called web framework
(look at this post or under the Basic Frameworks on the python.org site).
CherryPy calls itself an HTTP framework because it focuses on providing an API for managing HTTP. Frameworks which call themselves "web frameworks" typically ship with additional API's for managing databases, HTML/XML templating, javascript generation, RPC protocols and media types, and other components which are deemed useful for web development. CherryPy does not ship such components or API's, and therefore does not call itself a "web framework", although third parties may understandably do so when comparing CherryPy to other frameworks.
HTTP is a web protocol; there are other web protocols in use. An HTTP framework is a type of web framework.
CherryPy now calls itself a web framework. I guess HTTP framework that it used to be named was simply a poor name choice, probably influenced by the fact it incorporates a pretty advanced HTTP server.
Related
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 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.
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.
I am reading on internet about the difference between ASP.NET web service and WCF and have found that ASP.NET does not support any other protocol except http .
Can anyone please explain me the reason why ASP.NET web service don't support other transport protocols ?
It supports SOAP and other over-HTTP protocols. It is a design limitation, rectified with WCF.
ASMX web services are the original web service platform created as part of .NET 1.0. They are quite old, and the architecture is inflexible. In particular, they use the ASP.NET pipeline, which is focused on HTTP, not on multiple protocols.
They were replaced by WCF, which does not have these problems.
I'm wondering how many folks using the Microsoft development stack (IIS and/or ASP.NET) are actually using REST? If so, what forms of rest are being used?
REST can be categorized a zillion ways, but for the purpose of this question I'll categorize it as follows:
Radically REST: Using all the
HTTP methods PUT/POST/GET/DELETE
Moderate REST: Using GET/POST
REST Hybrid: Uses just the GET or
POST HTTP method, but follows
RESTful principles of addressability
and state.
In a class I'm teaching we've been trying to implement a "radically RESTful" service on IIS, but we've been having difficulty implementing the PUT method. There doesn't seem to be a lot of buzz on implementing PUT on IIS so I'm wondering how many people are actually using full blown REST? Are you using REST?
I'm involved in a project that uses WCF REST on IIS, but of course I'd recommend having a look at the framework I built: OpenRasta is a .net open-source stack that makes implementing REST much easier.
Google is your friend. The main site is http://trac.caffeine-it.com/openrasta.
I think part of the reason for the lack of buzz around REST on the IIS stack has been Microsoft's original adoption of SOAP as the way, truth and light when it came to web services - especially with Windows Communication Foundation being heavily SOAP focused.
They went on to release the WCF REST Starter Kit, to follow on from the release of .NET 3.5, and also the ADO.NET data services that are part of .NET 3.5 SP1.
As Magnus points out, Microsoft have since released the ASP.NET Web API which builds on the features of the ASP.NET MVC platform to provide a unified approach to RESTful services on IIS.
ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
The WCF Rest Toolkit mentioned in the answer from "Zhaph - Ben Duguid" is now deprecated.
It has now been replaced with the WCF Web API project.
Edit: Which is now also deprecated and replaced by ASP.NET Web API!
It depends how you approach it.
By default IIS will limit verbs to ASP.NET pages to GET, HEAD, POST and DEBUG. You are, of course, free to tell it to accept PUT as well by editing the handler mapping. Assuming you wanted your own extension you'd do something like
<httpHandlers>
<add path="*.example" type="System.Web.UI.PageHandlerFactory" verb="GET, HEAD, POST, PUT, DELETE, DEBUG"/>
</httpHandlers>
If you want to remap .aspx you, of course, can in much the same way, assuming the server is configured to allow you/
I'm pretty sure the Microsoft ADO.NET Data Services uses RESTful services. It might be worth checking out... aside from being restful, it's a really cool tech.
Here's an extract from a white paper on it:
The goal of Microsoft® ADO.NET Data Services is to enable applications to expose data as a data service that can be consumed by web clients within corporate networks and across the internet. A data service is reachable via regular HTTP requests, using standard HTTP verbs such as GET, POST, PUT and DELETE to perform CRUD operations against the service. The payload format used by the service is controllable by the application, but all options are simple, open formats such as JSON and Atom/APP.
Here's a white paper and it's home page (at least what I think is it's home page)
HTHs,
Charles
What version of IIS? In IIS6 you need to enable WebDAV to enable PUSH requests to get through (no, I don't think that makes much sense either :-)). I don't think that's the case in IIS7 though.
I'm using the .Net class, HttpListener, which is the IIS web server engine(http.sys) without the IIS admin tools. I am handling all of the HTTP verbs. You can add attach the ASP.Net runtime to this if you like, but you don't need to.
In fact in a few cases we implemented a version of PATCH as an experiment. Once you get down to the basics, the verb is simply a string in one of the HTTP headers.
You actually cannot categorize REST in a zillion ways. There are may ways of using HTTP to build distributed applications but there is only one definition of REST.