REST, RPC, and Brokered Messaging

This article explores three popular styles of communication in service-oriented architectures and how to chose the appropriate style for a given use case.

Considerations

Representational State Transfer

HTTP request                           Method name
--------------------------------- -------------
POST my-bucket.s3.amazonaws.com CreateObject
GET my-bucket.s3.amazonaws.com ReadObject
PUT my-bucket.s3.amazonaws.com UpdateObject
DELETE my-bucket.s3.amazonaws.com DeleteObject

Remote Procedure Call

// Redis protocol as RPC interface for caches 
// We can think of Set() and Get() as RPC calls
err := cache.Set(key,value).Err()
val, err := cache.Get(key).Result()
// JDBC protocol as RPC interface for databases 
// We can think of executeQuery() as a RPC call
Statement stmt = dbConn.createStatement();
ResultSet rs = stmt.executeQuery(sql);
Service A  <=>  Service B  <=>  Service C  <=>  Service D
Observing RPC calls traced in a large distributed system (https://sudo.hailoapp.com/services/2015/03/09/journey-into-a-microservice-world-part-3/)

Brokered Messaging

The basic Message Broker pattern (source: http://activemq.apache.org/clustering.html)

Conclusion

REST, RPC, and Message Brokering working together in a distributed system. In this diagram REST services most browser-based UI interactions, particularly over public networks. RPC makes up the majority of inter-service communication as well as a few UI requests. And messages are brokered across services and data stores that rely on pubsub streaming. Each component satisfies a domain and communicates with other components using a domain-specific semantics.

Staff Software Engineer at Stripe