Strategy for minimizing dependencies between internal subsytems in a RESTful Java ecosystem

The architecture of our system is such that there is a set of functionally subdivided RESTful subsystems. Many of these subsystems not only have to respond to requests from browsers but also to other subsystems. The inter-subsystem traffic is relatively heavy and needs to scale, so the decision was made to use serialized Java beans as the representation for this type of communication (due to the speed of serialization/deserialization). This in turn introduces a binary dependency between subsystems which have a client/server relationship. Changing the intern开发者_如何学Goal structure of the Java beans that are exposed via the RESTful API can have version compatibility consequences with client subsystems. Of course changing the structure of a representation of any content-type will have compatibility issues, but this is obviously worse.

Since one API can service many clients, coordinating releases of every set of dependent subsystems is an unattractive option.

This must be a common problem and I wonder how do other people solve/mitigate?

---

One option might be to communicate between subsystems using something such as protocol buffers. From what I understand, they were designed for just the sort of thing you're describing, particularly with regard to making compatible version changes.

---

I'm not sure if I correctly understand your question. I guess it's about interface versioning, e.g. one operation and/or object may exist in different versions and is used by different client systems, let's say:

ClientA uses InterfaceA
ClientB uses InterfaceA
...

In the SOA world it was solved by namespacing the different (WSDL, XSD) versions, so that you can implement some governance around the interfaces:

Time t0

ClientA uses InterfaceA.v1
ClientB uses InterfaceA.v1

Time t1 (new version of InterfaceA)

ClientA uses InterfaceA.v2
ClientB uses InterfaceA.v1

Now you can implement processes to enforce ClientB to migrate to InterfaceA.v2 at a certain point in time. In general those concepts have been developed for the WS-* world, but you can apply them to the RESTful world as well (I did this several times). A nice MSFT article: http://msdn.microsoft.com/en-us/library/ms954726.aspx.