Just What Are Spring 3.2 Matrix Variables? - Part 1

Spring 3.2 introduced support for processing something called 'Matrix Variables' and probably like most developers, I've never heard of them. So, after some research, this blog is my understanding of what they are and what you can do with them. As usual, please feel free to correct me if I'm wrong.

When I first read about them a whole bunch of questions came to mind, for example:

• What are they?
• Why use them?
• Why do the Guys at Spring think they're important?
• Why now?

What Are They?

Matrix variables, new to Spring 3.2, are described in the Spring documentation. This refers to RFC3986 and a document by Tim Berners-Lee from 1996. If you Google Matrix URIs then you don't get much help, and between you an me, RFC's are always written in a really boring way using a dull, plain text, format, which probably discourages people from reading them. The relevant section of RFC3986 is:

URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URI's dereferencing algorithm.

From this you may glean that Matrix URIs are a way of specifying arguments as part of a URI. Now, you may say, I can already do that using request parameters of the form:

http://localhost:8080/myappname/mypath?var1=hello&var2=world

In terms of Matrix URIs I guess that this translates into something like:

http://localhost:8080/myappname/mypath;var1=hello;var2=world

So, what else do they give you? Lets take a step backwards for one moment and come up with a scenario for which I'll write some code in my next blog. In this scenario I'm writing a stocks/share portfolio application and this application receives an HTTP GET call that as whole bunch stock names and prices attached to it.

http://localhost:8080/spring_3_2/matrixvars/stocks;BT.A=276.70;AZN=236.0;SBRY=375.50

In this example, I've got my spring_3_2/matrixvars application which specifies three stock names 'BT.A', 'AZN' and 'SBRY' and their associated price. This covers the same scenario as above; however, stock data doesn't just come with prices, it comes with all kinds of optional details: change in price, percentage change in price and so forth. Using a comma ',' along with the semi-colon we can add this additional information into the URI:

http://localhost:8080/spring_3_2/matrixvars/stocks;BT.A=276.70,+10.40,+3.91;AZN=236.00,+103.00,+3.29;SBRY=375.50,+7.60,+2.07

The above URI demonstrates that Matrix URIs give you the ability to attach collections of data to any part of the URI. In saying collections you also get the idea that the data you can attach is variable and can appear anywhere in the URI. For example, if the data required to complete the above URI was incomplete I could easily write:

http://localhost:8080/spring_3_2/matrixvars/stocks;BT.A=276.70,,+3.91;AZN=236.00,+103.00;SBRY=375.50

…submit it to my application and still be valid.

The next point to make is that the matrix variables have a hierarchical dependency. In the example above, the stock information (eg: BT.A=276.70,,+3.91) pertains to the stocks part of the URI path. This means that I can add different matrix variables to different parts of my URI:

http://localhost:8080/spring_3_2/matrixvars/stocks;BT.A=276.70,,+3.91;AZN=236.00,+103.00;SBRY=375.50/account;name=roger;number=105;location=stoke-on-trent,uk

In the example above I've still got my stock price information, relating to the stocks part of the URI, but now I've also added in some account information, informing my application that roger, account number 105 from the UK has BT.A, AZN and SBRY in his portfolio. Obviously, the account information relates to the account part of my URI.

Why Use Them?

From the previous section, I think that you should be able to guess the answer to this one. Matrix URIs or Matrix Variables, as the Guys at Spring call them, give you a new way of handling a variable number of URI arguments and the ability to handle the increasing complexity in the amount of data that's passed to an application using a HTTP GET.

Why do the Guys At Spring think they're important?

Now I can't speak for the Guys at Spring, but like you I can take a guess at what they might be thinking, so to the Guys at Spring, if I'm wrong here please let me know. I imagine that they might answer something like this: Matrix Variables increase the flexibility in the URI that can be processed by a Spring @RequestMapping method, thus meeting the demand for ever more complex and highly interactive web applications. They also neatly plug a functionality gap in the Spring armoury bringing Spring into line with JAX-RS, which already supports this technology.

Why Now

The final question has to be Why Now?. After all this idea dates back to 1996, so what makes it relevant to today's world? I guess that the answer to this question lies in what web applications are being asked to do. Highly interactive pages are all the rage, pages that are updated using AJAX and JSON without the need for a full screen refresh. JSON provides the answer to the need for complex replies to requests for information and Matrix Variables give you the ability to frame complex requests. In that sense, this may just be technology who's time has come.

All I need now is some code to demonstrate my stock portfolio scenario, but more on that next time.