The Importance of Context

We just had an issue at work with a new internal client using a service call we have set up differently than previous users. Let me see if I can relate the problem at a high level.

Suppose you have a website that is global, like a blog. You have ads on the page that pay for your blog site, so you want them to show. In your code, you serve English ads for the English speaking audience and Spanish ads for the Spanish speaking audience, etc. But, if an individual ad is ONLY available in English, you want it shown none-the-less. So, you roll up on the individual level.

Under the hood, you have a service that pulls the ad and automatically rolls up on ads only available in the “default language” (in this case, US English).

Now, you expand the service to other items and one of them is polls and you decide to use the service to not only display the poll, but create the link to navigate to the poll (yes, I know a method that solves multiple purpose ends up being a really bad jack of trades, but roll with me, as I inherited this). You only want to show the items in that particular language.

That is the crux of the problem. The norm is to rollup, but this one client does not want that. (Actually, this gets much deeper and if I were to explain the architectural solution employed, you would not believe me, as it sounds so preposterous).

Thinking RESTful?

I have the question mark above, as this really does not have anything to do with REST, but is something that you more often see in REST as you are dealing with representations of state. In order to pull an customer from a system in REST, whether by ID or last name, the object (state) has to contain the information you are using to pull it. Not 100% true, but the norm.

There is a good reason to employ this in nearly any (or perhaps all) situations where you are getting information outside of your process space (for example, calling another server). Let me illustrate:

Example 1: No Context

Give me all users with red hair that live in Nashville and speak fluent Mandarin Chinese and Japanese

Answer: John Doe and Jane Doe

Example 2: Context

{ Name: John Doe; Location: Nashville, TN; Languages: {english, mandarin, japanese, german}, Eyes: blue}
{ Name: Jane Doe; Location: Nashville, TN; Languages: {english, mandarin, japanese} Eyes: Brown}

Someone can now state, but I only want user’s with blue eyes and filter at the end. This is impossible if the context is not thrown back.

Now, in the software I am working with, we actually get a set that would include people that only spoke english, due to rollback, so I would have to filter out those who only spoke English after the fact. But I can do this.

There is another benefit to context. Suppose I thought I asked for films that had Mark Hamill (think Luke Skywalker) in them and got back the following:

  • Friday the 13th
  • Footloose
  • The River Wild

Something obviously wrong. But, if I had the context returned in the answer, I would see that the context was Kevin Bacon and not Mark Hamill. Oops. Now I can check and see if I accidentally sent in Kevin Bacon and it was my problem. Without the context, however, I have to know enough about movies to make an educated guess.

What’s the Point?

In general, when you are dealing with software, you should return the criteria for a request with the response. I say, in general, as there are possible exceptions to the rule, especially when you deal with network hops introducing latency into systems where reduction of the data set to what is required to render the answer, without the extra weight of the context. I say possible exceptions, as I believe you should make sure the latency issue is big enough to create a system that is harder to debug and maintain.

Is this realistic or necessary? Since many developers don’t understand how TCP/IP and HTTP work, and rarely ever have to dig that deep, the answer might seem to be no. But, if you understand how the underlying protocols work, you know there is a lot of chattiness and redundancy in the system.

The chattiness and redundancy don’t add anything most of the time, but they are very valuable when a browser team needs to filter out items that can, as an example, cause a cross-site scripting issue. By examining the headers sent, we can see that some of the information is coming from a different site than requested.

This may not be the best example, but considering that HTTP is stateless and context is passed with every request, there is a lot of data there to examine if there is an issue. Ultimately, being able to quickly solve issues is more important, at least in most cases, than reducing the size of a payload by eliminating context.


One of the issues that ends up costing a lot of time is trying to determine what is causing an issue in a system. Without parroting back the context, it is often difficult to determine whether the issue was sending in incorrect data or a server/service bug. By comparing context sent in to context returned, you can more easily determine the nature of the problem and the solution. This can be worth its weight in gold.

Peace and Grace,

Twitter: @gbworld