HttpHandler was a standard method of intercepting and modifying the processing of an http request in ASP.NET.
HttpMessageHandler is the underlying type for the DelegatingHandler, which is the standard method of intercepting and modifying the processing of an http request in ASP.NET MVC and ASP.NET WebAPI.
But you can still use HttpHandlers in ASP.NET MVC and WebAPI.
So what is there difference between these two? Assuming a pipeline containing one of each, when does HttpHandler.ProcessRequest fire in the pipeline as compared to HttpMessageHandler.SendAsync (i.e. which fires first)?
This is just two different things. Web Api introduces another alternative to intercept http messages. You can use them both if you will.
As for the sequence:
It looks like:
If you are interested in more details regarding ApiControllers/AuthorizeAttributes and DelegatingHandlers you can read my post:
http://dotrelusion.blogspot.de/2014/05/web-api-claims-authorization.html
Related
I am implementing an enterprise web application in ASP.NET MVC 5. In many situations I am writing AJAX gets and posts and communicate with the server app. Currently I am writing controller actions to serve those requests, typically returning with JSON result. The action methods parameter binding also seems work seamlessly when I passing JSON at client side.
I do not want to go far with a not appropriate practice, so the question arises, what could be the advantage to add Web API support to my project, and refactor my current ajax - controller practice?
There are few advantages according using WebAPI over MVC + Ajax:
Internal serialization
WebAPI has an internal serialization, which makes returning specific data much more easier, without your own extension method or making your controller dependent on the serialization framework library.
Action result helpers
You can use plenty of action result helpers like Ok(), NotFound(), InternalServerError(), which all return IHttpActionResult, what makes your code easier to read and maintain and clearly state your intention.
Action result abstraction
Using IHttpActionResult you can easy abstract result, which is helpful when unit testing your controllers.
Available to self-host
Using OWIN you can easily self-host your WebAPI project, what makes your application much easier to maintain and IIS-independent.
Native attribute routing
WebAPI has implemented attribute routing which makes all routing configuration much more easier(and helps when using feature-based architecture).
DI configuration improvements
Both WebAPI and MVC have their own composition roots and different DI implementation. Microsoft has introduced some improvements in WebAPI to make it easier to use and maintain.
I'd say that using MVC + Ajax was viable only when WebAPI didn't exist because there was the only option.
If your project clients needs data in multiple formats (json,xml,csv) or have chance to change in future Wep Api needs minimal configuration comparing to mvc. Wep Api returns data to client according to content negotiation (if client needs xml returns xml,if json return json according to request header ) but in mvc you need more code to satisfy that.You have to explicitly specify data format when writing action methods.(JsonResult,ActionResult,XmlResult)
Wep Api gives you more meaningful idea about what you are doing when you look at the code later.Comparing method signatures;
public List<Student> Get() has more meaning than public JsonResult Index().
Light weight & Easy to use.
Less data transfer between client and server.
Using webapi we can develop cross domain application.
Less configuration needed as compared to WCF.
It’s simple, scalable and robust because it supports all the MVC features such as routing, controllers, model binders, IOC container, action results, filter, or dependency injection as it is built on top of Asp.Net MVC.
Empower the developers by handing over control over the way HTTP protocol messages are sent and responded to.
Unit testing is easy as it support test driven development.
It provides ample flexibility in web API creation due to content negotiation and drives support for the ASP.NET routing.
Unlike WCF REST services, there is no need to define tedious configuration settings for different devices.
The architecture of web APIs is very light, which makes them a perfect alternative for the developers when they want to build applications for devices with limited bandwidth.
Web APIs are used to create non-SOAP-based HTTP Services, so if there is a requirement for web services, but not SOAP, then ASP.Net Web API is great to look for.
Supports different message format like json, plain text and xml.
Asp.Net Web API supports convention-based CRUD Actions since it works with HTTP verbs GET, POST, PUT and DELETE.
I am using WebAPI to develop a REST based communication model for my clients.
To intercept the incoming request and log them, I use a class that is derived from MessageHandler and register it in the WebAPIConfig.
Note: I never happened to work with legacy ASP.NET Web applications.
When I attended an interview yesterday, the interviewer asked about HttpHandlers in ASP.NET.
Is the HttpHandler so called MessageHandler in WebAPI or both are different ?
You can say that MesssageHandler is to Web API what HttpModule is to pre-vNext ASP.NET.
An HttpHandler in ASP.NET has a role more similar to an ApiController in Web API request pipeline: it is delegated requests and returns something in response.
While explaining concepts of ASP.NET MVC to my students
MVC is stateless. It is built on top of another stateless
protocol - HTTP and HTTPS
But one student interrupted and asked,
You tell that the MVC is stateless
Stateless protocol never cares if the response comes back or not from
the server. But, in ASP.NET MVC framework, you make a request and wait
for the response. Since you wait for the response, it should be called
as a stateful service. How come you are calling it a stateless service
then?
I really got stuck up and wondered what to answer to this question.
Any ideas?
MVC is not stateless, HTTP is.
HTTP being stateless doesn't mean it is fire and forget. The client does wait for the response. It is stateless in the sense that two successive requests have no relation whatsoever.
State can be emulated using sessions, for example using cookies.
The assertion in the question, purported by the other student it wrong. A stateless protocol like HTTP sure does care if it gets (or never gets) a response!
[A stateless protocol] treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response.
Of course, MVC isn't even a protocol .. but the same notion can be extended. It is "stateless" insofar as all the information is encoded in the request and response as a "pair". In practice, most usages are not truly stateless.
Please keep in mind, that there are a lot of different implementations of the concept of a model-view-controler architecture. There is no "correct" MVC. ASP.NET MVC cannot be is not a "perfect" implementation of the model-view-controler pattern!
Otherwise of thinking of stateful/stateless MVC. MVC can be understood by thinking of responsibilities:
The View is not allowed to change the state of the model directly - only through the Controller. The view can still have some direct access to the Model although only for viewing (or by having a copy that isn't the official Model).
The Model should live in its own universe and not have any reference to controllers or to views.
The Controller controls the state and access to the Model.
How they all interact with each other, can be implemented very differently (based on the platform for example) ...
MVC is not a protocol is a software architectular pattern.
On the other hand, HTTP is a protocol.
In nowadays the MVC pattern is very popular among many web frameworks. These web frameworks and the rest of other web frameworks are used for the development of web applications.
In the context of web applications HTTP is an application protocol that is used from browsers for their communication with the servers that host web applications.
Indeed the nature of HTTP is stateless. There isn't anywhere in HTTP the concept of state. For this reason, in many web frameworks, there are different ways through which we try to implement the concept of state. For instance in ASP.NET Web Forms the ViewState was developed for this reason.
That being said, MVC has nothing to do with the stateless nature of HTTP.
I have an HttpModule for my NHibernate Session Management.
The problem is that when pictures are loaded each request will invoke my HttpModule and creates a new ISession, which is a kind of stupid.
It would be nice to configure the HttpModule so that it is only invoked for MVC requests. Or otherwise the HttpModule should not invoked by requests for images, css, js and so on.
Is there a way of doing this?
Firstly the overhead of creating a new session is not very big - it doesn't necessarily connect to the database.
Secondly, you can open and close the session using a Filter instead of a Module in MVC if you only want it for MVC requests
To answer the question, use a regex to look at the Request.Url to match on file extensions you don't want to process and return without processing.
I have implemented the Session per request pattern for managing nhibernate sessions.
Because it is an httpmodule it runs for every request, be it a jpg or png. Is there a way to only get the module to create a session if the request is made through the MVC framework? I.E excluding png/jpg etc?
Mathieu is right, however it is a good practice for ASP.NET MVC projects to open sessions in an ActionFilter class.You can register it in GlobalFilterCollection, if you want it to run for every action. Take a look at this blog post (also from Ayende, but MVC specific).
Don't bother with that, creating a new session is just newing a few objects. Full explanation here from Ayende : http://ayende.com/blog/4123/what-is-the-cost-of-opening-a-session