Tech Life of Recht

As you probably know, I’m involved in the OIOREST work for NITA. The work is progressing slowly, but recently I’ve had some thoughts on REST which I thought were sharable.

First of all, REST invites to a completely new kind of architecture. Nothing new here, it’s been known as mashups for a while, but I don’t think the relevance of this has been very obvious. Mashups are often taken to be something non-enterprisey about combining data in new ways, preferably in the browser by using some sort of Javascript. One thing is the possibility of combining data in new ways, but equally interesting is the fact that a lot of data manipulation is moved from a central service to distributed clients. In the good old WS-* world, mashups are known as ESBs. An enterprise service bus, whatever that is, is orchestrated into making web service calls to different services, transforming the results, combining them, and returning a complete document to the caller. The net effect is more or less the same: You get a page with the data you wanted to see (hopefully), but the ways it’s done are just about as different as they can get.
I’ve been on quite a number of projects where one service had to call another service in order to return a complete result. This gives long chains of service calls, and lead to highly coupled systems which are not very fault tolerant. With REST, it’s suddenly much easier to just return a document with references to other documents, and if it’s necessary, the client can fetch the other documents, and in the process utilize HTTP caching and other well-known mechanisms. This way, a client can fetch a root document, and immediately show the page and then fetch the rest of the data – what Martin Fowler calls Segmentation By Freshness.
Unfortunately, I’ve not seen any “enterprise systems” use REST like this, but I can’t see why it should not be possible, and even better than the WS-approach.

The second point about REST is about privacy. This is a hot topic in Denmark at the moment – a new national digital signature is on the way, and we’re helping NITA implement Single Signon using SAML 2.0. SSO makes it easier to acccess protected resources, but it also makes it harder to maintain privacy as a citizen. Most people look at SSO and the government pragmatically and trust that the government will do no harm. I guess I belong to that group to some degree, but other people, like Stephan Engberg maintains that the government should not be trusted, and that data should forever be owned by the person behind it, and nobody but the person should be able to combine it with data from other systems. Typically, this is accomplished by using pseudonyms – the person essentially gets a new identity for each system, and nobody knows all the identities (unless the person revals some or all of them).
I quit agree with this, I just can’t see how it can be implemented just now. However, REST looks like a good technology to use here. REST is relevant because, as mentioned above, it moves the responsibility for combining data from a closed system to an open client. With REST, a client can retrieve data from different sources, using different identities, and combine it locally, and the person behind the computer will be the only one to ever know. The same principles apply when
Of course there are details like XSS, trusting the client code not to do something wrong, and so on, but again: it’s all based on an open platform, and if you’re worried, you can make your own client.

I doubt anything like this will happen anytime soon – the tax office probably won’t like not being able to combine data automatically to prevent fraud, so we’ll probably just work on REST services which are not people related for now.