GET-only REST Integration Patterns Blur The Line Between Synchronization And Integration
Duncan Cragg explains his idea/pattern for a purely GET based REST integration pattern, which turns out to be very similar to the vision of Microsoft's FeedSync Specification. He explains the pattern with the help of hypothetical conversation with an enterprise architect
Our worried Enterprise Architect noticed that such Service-Orientation permeated REST practice: there were "REST APIs" to Web sites, or "Web services" with a small 's'. Even AtomPub had a "service document"! Some patterns, like AtomPub, offered just simple read/write data services through the full HTTP method set. Some simply used such a read/write interface as a wrapper around more complex service functions.
He wondered: "Where's the Web in REST integration? The Web works great without PUT and DELETE: isn't using GET on its own RESTful enough?"
He calls his GET based integration pattern, FOREST, a RESTful observer synchronization pattern, as he explains
FOREST is a GET-only REST Integration Pattern defined simply as: A resource's state depends on the state of other resources that it links to. [...] This means that resource servers must also be clients in order to see those dependencies.
He goes on to give a few examples of such integration scenarios including mashups …
FOREST is a REST Pattern derived from GET-only or polling Web use-cases, including certain kinds of mashups for e.g. feed aggregators or filters, sites that create summaries of other Web pages etc.
… and its relevance in enterprises.
FOREST is a REST Pattern for building "Enterprise Mashups" in an ROA / WOA / SOA. [...] Enterprise Mashup Markup Language is the nearest thing to this that I know about, but FOREST is quite different: it is much simpler and is /only/ a REST Pattern.
As such the idea of using GET Based synchronization of ATOM/RSS feeds has already been around a while in the form of FeedSync, a feed synchronization specification from Microsoft.
The scope of FeedSync for Atom and RSS is to define the minimum extensions necessary to enable loosely-cooperating applications to use Atom and RSS feeds as the basis for item sharing – that is, the bi-directional, asynchronous synchronization of new and changed items amongst two or more cross-subscribed feeds.
This is a form of integration in which resource representations, typically the canonical data model, are exposed as a feed, that, endpoints can use for pull-synchronization. The idea that these endpoints can be devices, services, applications etc. that can synchronize resource state over HTTP using GET semantics will only make variations of this pattern more ubiquitous.