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.

Today, we had the OIOREST workshop, a workshop on the OIOREST initiative, we’re a part of at Trifork. The workshop was meant to inform about REST in the Danish public sector and to hear what users and developers had to say. The workshop went pretty well – not a lot was changed, but at least we were (more or less) confirmed in our view that REST does have its place.
The workshop was centered around a couple of Open Space sessions. One of the topics discussed was “REST vs WS-*”. While working with OIOREST, this topic has come up again and again: What is REST in relation to SOAP and WS-*, and when should each be used? This has been the basis for many heated discussions, and today was not much different. Most people say something like “REST is for simple things, but when things get too complicated, you’ll want to use WS-*”. I can’t really figure out what to think about this. First of all, what is simple and what is complicated? Complicated scenarios often include transactions and reliability. Distributed transactions are evil, period. Reliability is handled in REST by adhering to the HTTP verbs and keeping operations idempotent, so that’s not really a good argument either. Another argument against REST is “now we’ve finally developed all these standards for SOAP, why should we then do the same for REST?”. Ignoring that REST is older than SOAP and WS-*, somehow this argument also feels wrong.

I agree that REST is not for everything: if you want a RPC interface, don’t use REST. If you work in an organization which is committed to SOAP-based web services, don’t use REST (at least not openly). If you have the need for hierarchical data in the message header, REST doesn’t quite fit. If you want to use only GET/PUT/DELETE/POST, it will for example, be hard to implement transfers between two accounts in REST.
Now, everything is possible, and all of this can be modeled in REST, but it’s starting to look wrong and diverge from “real” REST. Something like WS-Security seems hard to implement in a nice way in REST. WS-Security makes it possible to sign and/or encrypt XML payloads transparently. The signature is placed in the SOAP header, and the payload format does not have to support digital signatures directly. If you need end-to-end security, this is a pretty nice thing, and REST does not have something similar. Some payload formats, for example Atom Publishing Protocol, supports signatures as a part of the payload itself. WS-Security still has the advantage that no matter what format you’re using, you can use the same mechanism for signing and checking signatures.

WS-Security has some potential, but I’ve also seen a lot of cases where WS-Security could be replaced by plain SSL instead together with a simple Authorization header. So, the original question is still valid: what are the scenarios where SOAP/WS-* simply cannot be avoided? My guess is that there is no good answer for this, just as there is no good answer to the question “when should we use Ruby instead of Java?”, or “when should we use PostgreSQL instead of MySQL?”. The answers to these questions will depend on who you are, what your experience is, where you’re working, and so on. The only way is probably to try some different scenarios in REST and SOAP and see what approach is most successful – which is what we’re in the process of doing with the Danish Nature and Environment Portal, but more about that another day.

At Trifork, we have had a number of different consulting jobs in the Danish public sector, especially for the National IT and Telecom Agency (who is also sponsoring development of OpenUDDI). Among other things, we’ve been deeply involved in OIOWSDL, a WSDL profile for the Danish government. This profile specifies how to use WSDL and XML Schemas to do contract-first development. All in all quite reasonable – you can always argue whether the correct choices have been made, but at least you don’t have to make them yourself.
I had the somewhat doubtful honor of ensuring that OIOWSDL is compatible with all the popular platforms out there – which means that I’ve tested OIOWSDL-conforming WSDL and XSD with IBM RAD, BEA WebLogic, .NET 2 and 3, Ruby, Axis 1 and 2, and others. I already knew that web services were complicated, but that exercise really made the complexity clear. As an added bonus, I’ve been haunted by web services ever since because I’m now the guy who knows everything about them. This is also why the term WS-Deathstar is not accurate – it should be WS-Blackhole, because once you’ve come too close, you’ll never get away.

So, it was quite a change when we were asked to help with a REST profile (OIOREST). For me, it made perfect sense – REST provides much easier access to data, and interoperability is also much easier to accomplish. Unfortunately, it’s only in Danish, but we’ve taken the first steps and written a draft of the profile. The draft can be downloaded at oiorest.dk where you can also find an invitation to a workshop. The workshop is open for everybody who is interested, and the purpose is to extract experiences and attitudes towards REST.
oiorest.dk also sports two examples of what types of REST services we see. Feel free to play with them, but don’t use them for production.

It will be interesting to see where OIOREST will go from here. My hope is that more data will become public accessible – for example the Central Business Register, polution information, and all the other stuff that’s hidden away right now.