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.
I’m currently working on an open source SAML 2 toolkit for the National IT and Telecom Agency. Exciting stuff in many ways, but mostly because we might contribute to the adoption of SAML in a pretty constructive way. I still think that SAML is overly complicated at times, and the closed nature doesn’t make it very scalable – every service provider has to be registered in the identity provider up front in order for anything to work, which is a huge maintenance issue. However, with the right setup, it doesn’t have to be that complicated. We’re developing a servlet filter, which can be plugged into any Java-based web-application in order to protect it with SAML single signon. The work is based on code developed elsewhere, and when we received it, there were no unit tests. At all.
No tests is not exactly the best way to start off, so the first tasks on our backlog was to implement unit tests for as much as possible. While the code is not exactly legacy, it’s still written by someone else, and structured in a way that you don’t quite understand.
Writing unit tests under these circumstances neither easy nor fun. There are clear advantages, though: the code will be tested, and any further work can proceed with a much higher level of confidence, and the code will be refactored intensively in the process. The refactorings happen for two reasons: to better understand the code, and to make the code testable.
So far, the main obstacles for testing have been
- Passing around too “large” objects – for instance a HttpServletRequest only a single request parameter is needed
- Calling static methods
- Relying on static initializers to configure a class, for example from a file on the file system
- Using singletons and calling them everywhere
- Methods with side effects – why should a method named getId() put something in the HttpSession?
All of this can be refactored to make it testable. One can only wonder why it wasn’t written that way from the beginning. Anyways, the tests have been written, and the quality of the code base has increased considerably. Because of the tradition of always including new technologies in projects, this has also been the first time I’ve used JUnit 4 and jMock 2 extensively, and I quite like both of them. Especially jMock has helped a lot, and it has a very nice API.
For those who are interested, the SAML toolkit is based on OpenSAML 2, and will be released under an open source license (I’m guessing MPL) at Softwarebørsen at some time in the near future. It’s main focus is on supporting OIO-SAML, but it should support just about any SAML 2 compliant setup.
In Denmark, we have the OCES digital certificates, which are used for communication with the government, both for email and web signon. Web signon often runs through the OpenOCES java applet – a good old Java applet running AWT. Ugly as hell, but it works on just about any JVM or semi-JVM (like Microsoft’s).
Anyways, those of you who use it under Linux/Unix might have wondered how to put something in the dropdown box so you don’t have to go through the evil AWT file chooser every time you have to select a certificate. The documentation doesn’t really say it, but the trick is to put the certificate files (.p12 or .pkcs) files in ~/.oces.
Next time OpenOCES is activated, the files should be in the dropdown box. Excellent.
Apparently, some people has been wondering exactly who I am and what I look like. I’ve more or less kept this blog clean of personal matters without technical aspects, but guess I can make an exception. For those who are interested, I have a SmugMug gallery with all my pictures, and pictures of myself have been tagged.
Please do bear in mind that a lot of the pictures have been taken at parties, and often I try not to look the best.
While we’re at it, I managed to grab some pictures of Trifork’s new offices while they were still being built (last week).
REST vs WS-*
RSS feeds available for 
