Although many people think of cookies as a convenient way to store information between user visits, you can also use them within a user session to track session information. However, Cookies are intended to be short bits of text, and, if used to track user session information, you would probably find yourself storing more and more data in them. Eventually, you might wind up assigning ASP-like session IDs and use the cookie as a key to access state information stored on the server.
For example, you could store information for each user in a separate file, and then use the cookie to identify a particular user's file. In this case, you would essentially be programming your own version of what ASP does for you automatically. Using cookies without ASP means lots of extra work for you, which makes it less cost-effective to implement customized interaction.

Whether the subject is the older XML Web Services (a.k.a. ASMX services), WCF, services with ASP.NET MVC or with the ASP.NET Web API, the concept of service activation is present. Essentially, since by-and-large all calls to a service are new requests, the ASP.NET or WCF runtime activates a new instance of the service class for each request. This is similar to object instantiation in OO-speak. Note that service activation is a little more involved than simply having the application code create a new object. Understanding activation and dependency resolution is very important if you want to have a solid grasp of any service application, including the ASP.NET Web API.