Skip to content

REST-based architectural style, a big winner

Recently been deeply stuck in building software (apart from starting my PhD part-time). A long time ago I wrote about dynamically loading Spring contexts and component discovery – this system I’ve been building is an evolution of that one. We decided to adopt an most REST-based style to integrate between our components. Now, “run-time” discovery and configuration is easy, a matter of scraping REST URLs for the resources they contain (or even, just assuming a resource URL will be available and finding out its capabilities, or even its unavailability. at run-time). We’re using this architecture in places where you’d otherwise be employing messaging-based systems or pure-Java database service layers. Now we just convert the payload to XML/JSON and POST/PUT/GET/DELETE etc to a http URL! You’d think that this would kill performance, but we’ve found the degradation to be minimal (it helps that our transactions tend to be infrequent, but large in data set size). This is a big saving on complexity for our system – the transaction boundaries nearly always relate to the http URL calls so no more heavy reliance on things like XA transactions and JTA Transaction Managers. We still have them, as we need them in a couple of places for the moment, but it’s no longer such a big freaking deal for us in every situation.

Our system has generic components which “pass off” specific knowledge of specific data sets to specific processing components, where there are not a fixed set of these specific components available to all the generic components. In classic OO design this is achieved with interfaces and many design patterns like the Visitor Pattern. In our design we’ve replaced much of the complexity of the interface with REST-based architecture. Our application has become far more modular (despite its run-time complexity). More importantly, we are at the the point where we can easily start delivering the advanced features that the business has now specified for us without introducing a massive bloat-o-burger one-size-fits-all set of “common data definitions” that are the union of all possible sub-system functionalities.  Each sub-system can have its specific features required for that data set and still satisfy the handful of generic actions it is required to support. Each of these specific features can be developed in isolation. It’s a big win for us.