Lesson 11

This module covered the stateless nature of the http protocol, and some solutions to problems that lack of state creates when you try to customize the user's experience of your site. You learned how to initialize and capture session variables in the Session object to maintain user information, with an eye towards using that information to customize your site for its visitors. We also reviewed the Server object, focusing on its URL-encode method for ensuring that user information passed through a URL via "get" is properly formatted. Additionally, you learned how to incorporate one of ASP's components, the Advertisement Rotator.
Now that you have completed this module, you should be able to:

1. Explain why the lack of "state" on the Web causes difficulty in retaining user data
2. Explain how the Session object and session variables maintain user information throughout a site visit
3. Describe and create a Global.asa file with common user start and end procedures
4. Display a banner image or text that rotates through a series with the Advertisement Rotator component
5. Explain how the Server object can URL encode data that includes a space or other character not allowed inside a URL

Click the Quiz link below to test your knowledge of user sessions and session variables.
User Sessions Session Variables - Quiz

ASP.NET Web API provides a highly-extensible, simpler processing pipeline.
For example, delegating handlers (also known as handlers) and filters are mechanisms providing pre- and post-processing capabilities. Handlers allow you to execute custom code prior to any controller being activated within the application. In fact, handlers can be configured to handle routes that have no corresponding controller. Filters are essentially classes that contain a few methods allowing you to run some code before and after specific controller methods are invoked. These come in a few different flavors:

1. action filters,
2. authorization filters, and
3. exception filters.

These filters take the form of attributes, and they are either decorated on specific controller methods, decorated on the controllers themselves, or configured globally for all methods. It is a bit tough to describe, but once you write and debug a few controllers, along with a delegating handler and some action filters, you will start noticing how clean and easy Microsoft has made this arrangement. Nothing is hidden from you, making it simple to understand and step through an entire service call in the debugger.

1. Attribute Routing and Route Prefixes (new in ASP.NET Web API 2): Sometimes you do not want to rely on convention-based routing. With v2, you can use the Route, RoutePrefix, and various Http* attributes (e.g., HttpGet, HttpPost) to explicitly define routes and associated HTTP actions for your controllers. As you will see, this new feature makes supporting resource relationships much easier than was possible in v1.
2. Route Constraints (new in ASP.NET Web API 2): This very cool feature provides a mechanism for constraining various controller methods and their routes to specific business rules. For example, rather than just {id} in your route, you can now include something like

   {id:int}, {id:min(10)}, {id:range(1,100)},
   

   or even
   

   {phone:regex(^\d{3}-\d{3}-\d{4}$)}.
   

3. CORS Support (new in ASP.NET Web API 2): The new EnableCors attribute allows you as the developer of an API to allow cross-origin requests from JavaScript applications not in your service's domain.
4. Global Error Handling (new in ASP.NET Web API 2): This enormous improvement in error handling appeared in the ASP.NET Web API 2.1 release. All unhandled exceptions can now be caught and handled through one central mechanism. The framework now supports multiple exception loggers, which have access to the actual unhandled exception and the context in which it occurred.
5. IHttpActionResult (new in ASP.NET Web API 2): Implementations of this HttpResponseMessage factory interface provide a reusable, unit-test-friendly way to encapsulate results of your Web API action methods. The created responses flow through the outbound processing pipeline, so content negotiation is honored. In the example task-management service, you will see this used to set the status code and location header in response to POST requests.