Versioning RESTful Services

As I was explaining Representational State Transfer (RESTful) Service Oriented Architecture (SOA) to my customer, who require extensive modernization of an enterprise class system, they asked a very good question:

"Things change over time. If everything is service based, how do we handle versioning of the services, without client disruption. When one applications suddenly requires different information, we can't update all of the other client applications just to accommodate the needs of the one. We also should not be duplicating services fo every client that needs something slightly different."

Excellent question! There are myriad reasons to update a service, but only three major courses of action to follow. One of the three will be a best fit for each situation. Sometimes, things are just that easy. The options are few; because, the ultimate goal is to maintain integrity of the URLs. You simply don't want your service URLs changing, for many reasons into which I will not delve in this post. (If you are reading this post, you should know well enough to be nodding in agreement, anyway.)

To be clear, this post covers RESTful services, such as Web API, and not traditional WISDL-based Web Services or object serialization proxy services, like WCF. No, we're talking true REST.

Visual Studio 2010 Code Compare Line Length Limitation

The default code differencing / compare tool in Visual Studio 2010 contains a bug: lines of code over 4095 characters overrun the buffer and are not evaluated, nor do they appear. What concerns me is that the compare tool did not alert the user that a buffer overrun may have occurred.


Today, my colleague noticed a line of edited code missing from the default VS2010 code differencing / compare tool, used to locate changes in source controlled files. The edited line of code simply did not appear in the tool, and had no indication of containing a change.

Looking at the code in the editor, I noticed it was a wide line. Very wide. 5057 characters wide, to be exact. The code in question was produced by a meat grinder conversion of a legacy system, not only evidenced by this wide line of code, but also that this line was a call to a method that contains 218 input parameters. (Yes, the application actually runs.)

Inserting a line break after character 4095 confirmed this is a buffer overrun issue; breaking the line at character 4095 causes both lines to appear in the comparison tool, and to be marked as a change.

How to generate missing Fakes shims

While using the Fakes (Moles) isolation framework, you will notice some mscorlib shims are missing, particularly in the System namespace. For example, System.Fakes.ShimEnvironment does not exist. Although these are missing by default, you can request the compiler to generate shims for specific objects. This post provides steps to request Fakes shim generation for System.Environment and an example of implementation.

This tutorial targets Microsoft Fakes Isolation Framework on Visual Studio 2012 Ultimate or later; but, this process is also compatible with the developmental version, project name "Moles", running on Visual Studio 2008 or 2010. This tutorial assumes you have basic understanding of the MSTest framework.

Fakes added to Moles posts

Today, I am (finally) starting to update all of my posts on use of the Moles Isolation Framework to its official release version, called "Fakes Framework", included in Visual Studio 2012 Ultimate and newer.

To learn how to use both Moles and Fakes, click the "Unit Testing with Fakes/Moles Framework" link, below the page title on this blog.  Please bear with me, while I get the information updated.  I am very glad to see Moles come to market!