Pub/Sub’s Relationship with REST and RPC

by Kris ZypMarch 31st, 2008

I recently blogged about the relationship between REST and RPC. REST and RPC also have a relationship with the publish and subscribe architecture. Joe Walker recently discussed three major API styles for Comet: traditional, message-passing, and data synchronization. These API styles correlate to these three architectural styles, respectively: RPC, pub/sub, and REST. However, the architectures are not unrelated, disparate concepts. There is benefit in understanding how these architectures are related and interact.

RPC architecture is based on sending remote calls without any architecturally defined expectations on the behavior, and RPC alone can be viewed as the most generic request and response architecture. REST can be viewed as a form of RPC, in which the architecture does define expectations on the behavior of the remote calls. REST typically has defined a shared vocabulary of calls (GET, PUT, POST, and DELETE) with commonly understand effects.

A notification is a message that does not require a response. A notification may be viewed as similar to an RPC, in that it invokes a remote method, but it differs in that no response is necessary for the application logic. Some systems may provide an acknowledgment of the notification, but this is more of an artifact of the transport than the application semantics.

The pub/sub architecture bears some similarities to REST and RPC, but it is generally composed of notifications instead of requests and responses. Pub/sub has several key components. First, publishing an event is a type of message with a defined expectation, very similar to REST commands in that respect. The expected behavior of a publish request is that the published message be delivered to all subscribers of the specified topic or channel. The publish action resembles the REST POST command. POST suggests that the provided content or data may be appended to the indicated resource. With the publish command, the provided data is conceptually appended to the stream of messages for the given topic. There is also a notable similarity between a pub/sub’s channel or topic and REST’s resource locator or path: they both have a unique forgeable identifying string with path-style syntax.

The subscribe command can be viewed as a notification form of the GET command. The subscribe command is similar to a GET in that it is “safe” (no other resources or users are affected by a subscription), and it is idempotent (subscribing multiple times to a topic should have the same effect as subscribing once). The primary difference is that a GET command follows the request/response paradigm: a single GET request should be followed by a single response. The subscribe command may be followed by zero or more notifications from the subscribed topic.

Finally, when the published message is broadcast to clients, this is similar to a POST response. The message is informing the client of the result of an action that has been taken on the server. However, this is a notification message because it is not in one-to-one response to a request. Of course, a Comet message that is being delivered to subscribed clients does not necessarily have to be the result of an explicitly published message. A message to subscribers may also be the result of another action with side effects like a REST command, or caused by another asymetrical source.

Below is a diagram of the relationship between these different forms of messages:

Pub/Sub, REST, and RPC Venn diagram
Venn Diagram of Pub/Sub, RPC, and REST

Comments are closed.

Copyright 2015 Comet Daily, LLC. All Rights Reserved