RestMS defines a standard resource tree and defines how each resource is represented, and how a client can work with it. The semantics of message routing are contained in three key resources:
- The feed, to which publishers send messages.
- The pipe, from which subscribers read messages.
- The join, which ties these two together in an N-to-N relationship.
The notion of feeds, pipes, and joins is easily familiar since these names are used for similar types of resource elsewhere (such as RSS feeds, SQL joins, and Unix pipes).
However, the mechanics of exactly how messages flow from feed via join to pipe, are delicate. There are several ways to conceptualize a feed-join-pipe model, and it is unclear which of these ways is best, because abstract messaging models are a very new notion and the field is evolving rapidly.
To give some examples of the choices a model designer faces:
- Should the feed act as a queue, or should it route messages straight into pipes?
- Should the feed be persistable, and if so is this something the client can choose (by specifying a particular feed type)?
- Should the model be compatible with other models, such as AMQP?
- Should joins be passive (specifying criteria that feeds act upon) or active (pulling messages off the feed into their pipe)?
- Should it be possible to join any pipe type to any feed type?
- Are there intelligent default models that the client can benefit from?
And so on.
Rather than try to answer these questions directly in RestMS by embedding a single, fixed model (with a high probability that in several years the answers would be proven wrong), we define the messaging model as a profile, and make RestMS work with arbitrary profiles.
The real value of an abstract messaging system like RestMS is in the simplicity and effectiveness of its model. But the time it takes to develop better models depends on the inertia of the encapsulating protocol. If the protocol uses complex binary framing, then any change is expensive and slow to implement and test.
Given that RestMS is relatively easy to implement - for any developer with an HTTP stack and XML parsing classes - it can be seen as a rapid prototyping environment for profile development, and profiles can be seen as the key product of the RestMS ecosystem.