The discussion of Request.Cookies described how user data is not retained whenever the browser leaves one Web page for another. Speaking technically, the HTTP has a lack of state. This condition results in two separate difficulties for you to solve as you attempt to personalize users' experiences on your Web site.
As you have become aware, one of these difficulties is that you can't easily recognize visitors when they return to your site.
The other difficulty is that you cannot easily track a visitor as he or she moves through your site, makes choices, accumulates data, and finally completes the visit and leaves the Web site (we will refer to this as a user's session).
In an online store Web site, like our course project T-shirt store, both recognition and session tracking are important. If you ask a user to choose a preferred T-shirt size by clicking a radio button, the value of that button will be sent to the ACTION URL of the form. When the user moves on to another page, this preference is gone for good.

One solution to the user recognition problem has been to write and read browser cookies, but cookies have limitations when they are used for session tracking. CGI offers another possible solution by passing data back-and-forth through hidden fields, but this also has limitations as the data becomes more complex.
Because managing a user's state during a session is important, ASP includes features to make this task easier for you. Without custom programming, ASP's Session object enables you to track variables for a user's session through a file that is stored on the server, not the user's browser.
The next lesson describes how ASP's Session object maintains user information.

If you need to set up communication between two applications, whether they are co-located or separated by thousands of miles, rest assured WCF can do it. And if its out-of-the-box features do not suffice, WCF's tremendous extensibility model provides ample opportunity for plugging in just about anything you can think of. And this is where we will take a bit of a left turn, off the evolutionary path of ever greater capability and flexibility and towards something simpler and more targeted at a small set of specific scenarios. As this books is about building RESTful services with the ASP.NET Web API, we want to start looking at the need for such services (in contrast to SOAP/RPC style services), and also what types of features and capabilities they provide.
This concept of routing is critical to understanding how the ASP.NET Web API can be used for building services, so let us look at an example. In this course, you will learn how to develop a simple task-management service. You can imagine having a SOAP-based service method to fetch a single task. This method would take a task's TaskId and return that task. Implemented in WCF, the method might look like this:

[ServiceContract]
public interface ITaskService
{
 [OperationContract]
 Task GetTask(long taskId);
}
public class TaskService : ITaskService
{
 private readonly IRepository _repository;
 public TaskService(IRepository repository)
 {
  _repository = repository;
 }
 public Task GetTask(long taskId)
 {
  return _repository.Get<Task>(taskId);
 }
}