Why does MVC have session and not Web API?

This is a question that I have been asked recently, although not in this exact form. In order to understand why features like Session are not provided as standard in Web API, it is important to know the difference between the consumer of each product.

MVC is for browsers

Browsers do a lot more than we like to think about. We all understand that we make an HTTP request, the server returns some HTML and the browser renders it in beautiful shapes and colours. Browsers do a lot more under the hood. Take for example, caching; the server will usually provide some hints about how a browser should cache the response within the HTTP header. Browsers follow a set of standards and ensure that certain actions are fulfilled; this is why a browser will read this header information and cache the response as instructed.

Another feature that browsers are good at handling is cookies. Cookies are sent via the HTTP header by the server. The server knows that the browser will follow instructions so it gives instructions  such as Set-Cookie: name=value. When the browser receives this instruction, it stores the cookie somewhere so that the next time you request a page from the same domain, it can send this information back to the server through the HTTP header.

Cookies are quite powerful because it allows a server to send a browser some information that it knows it will always receive back from the same user. Using this information, a server can send a unique ID to the browser and register that same ID in memory. Then it can assign a whole bunch of data to that id (like a programmatic dictionary, ID:18943001 contains: {data data data data}). Now it knows that when the recipient makes another request, it will send back the same cookie the server sent originally. The server will check for this cookie and match the ID to its memory bank and find all of the data associated to it. This is Session in its most basic form.

REST clients are stupid

Compare a browser to a REST client. There are no strict standards to uphold in a rest client; you make a request and your request is defined by data that you send via the HTTP header, URL and sometimes, the HTTP body. You then receive a response; this contains only the HTTP header and body. Since there are no standards to uphold, you are closer to the metal. You have more flexibility over what data you send and receive and how it is formatted. This usually allows you to cut off the fat and make your requests and responses much smaller.

Cookies don’t exist; they never did, it was something invented by a conspiracy between browsers and software designed to provide data to browsers. If a server told a REST client to save a cookie, the client would ignore it; it doesn’t know the specific language the server is talking in. It is up to you to interpret that instruction, handle and save it. It is also your responsibility to ensure that the next call to the REST API contains that cookie information in a format that the REST API understands… That is if you would like the server to know what data to associate to your request as the “session data”.

It is important to understand that a browser is a REST client. But one with a strict set of standards and rules. These standards allow software from an infinite number of servers, written in an infinite number of languages, following an infinite number of design patterns, to provide data to browsers in a consistent manner so that clients know how to handle the response and provide a visual webpage to the consumer.

Why can’t Web API have sessions?

They can; the REST protocol just does not have a standard as to how to implement this feature like the web does. So go ahead, re-invent the wheel (not being sarcastic, read on). The best part about it is that you decide how to differentiate between clients yourself and this could mean a smaller footprint across the wire. Just know, that because there is no standard way to support cookies (or a similar concept), Microsoft’s Web API will not try to invent it for you or even try to provide it. No cookies, no standard way of providing sessions, Web API can’t possibly know how to handle sessions for you so it won’t try.

REST and HTTP are stateless

Ok, this is one thing I need to clear up. HTTP is a protocol that allows you to send data; REST uses HTTP. HTTP is stateless, but Web is not. That is why websites can appear to be stateful; there are standards in place to help browsers and servers to work together and share state. REST on the other hand is not designed to promote statefulness and provides no standard way to achieve stateful transactions, this is why REST is stateless.

I read somewhere a good example of stateful and stateless protocols.

  • A stateful protocol would authenticate once and keep an open connection. This would allow commands to be sent to the server as single requests until the connection was closed.
  • A stateless protocol would connect, authenticate, and issue its command in one request. Then after doing this, the next request will have to do the same again.

Don’t be fooled by the word authenticate, authenticate may indicate sending username and password, but it can also mean providing a unique identification token (cookie) if the security is not as big of an issue. After providing a username and password once on a website, an identity token is usually enough to authenticate without requiring the username and password again for subsequent requests.

Advertisements

One thought on “Why does MVC have session and not Web API?

  1. a statefull service providing object is not an object which needs to be re-established for each request ! the framework, what ever type it is, supports this statefull service providing objects. each user session, once established to be connected with his own object, can be assured, that the state of this object is not change in between request unless foreseen by the application logic of the object. (i.e. a state machine or else) the framework make sure that the state of the object is not lost in between requests, that the object can not go out of scope and hence can not be collected by i.e. a garbage collector or returned to a pool of available objects.

    stateffulness is achieved i.e. using the axis2 web service engine by adding scope=”soapsession” to the service.xml (service engine returnes a ServicegroupId in the soap header, which needs to be provided by the client with each request)
    statefullness is achieved i.e.at WCF using a WsHttpbinding and setting reliable session true.

    Be warned: state is maintained only as long as the service host is not re-cycled by i.e. an IIS host, or as long as no relevant time-out ocures.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s