Most web browsers support only HTTP methods like GET and POST and do not support PUT and DELETE.
If so, does web servers like IIS and Apache support it? Why should them support if the web browsers don't supports them? Those methods can be used for something else?
Web servers support these verbs because they are part of the HTTP specification and because browsers are not the only clients of web servers especially in the Web 2.0 era. There are more and more RESTful APIs today.
Related
I am exploring the current news for ASP.NET WinForms with .NET 4.6.
The resources I am currently looking at is this Video overview by Microsoft Program Manager Pranav Rastogi and an article on DotNetCurry. Besides the information, that I will require Windows 10 Preview, I can not decipher, what this really means to me as a WebForms developer.
To use HTTP/2 will I...
need to make some changes in a config file?
need to change something in the page / master page?
use a different programming model when it comes to serve resources?
Of course, IIS will need to be configured, but this does not affect me as developer.
Is there actually something I need / can do as developer to support HTTP/2?
Note: If someone sees this as a better fit on Programmers or other SE site, please move.
Basically, HTTP/2 is seemless for web services. The basic functions, request/response multiplexing and header compression, are defined at the network protocol level. That means it can be seen as the matter of web browsers and web servers.
But for the new features like HTTP/2 server push and stream priority/dependency, it needs to be considered for developers. To use those features, web browsers and web servers should provide APIs.
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.
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.
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.