Service API Patterns, Protocols, Coupling Types, Metrics > Service API Design Patterns > Dual Protocols

 

Dual Protocols

How can a service overcome the limitations of a canonical protocol while still maintaining protocol standardization?

It is preferred for all services within a solution or domain to interact using the same communications technology. However, when standardizing on one protocol is not possible or when the chosen communications technology is inadequate for certain types of data exchanges, it can compromise service interoperability.

With the application of the Dual Protocols pattern, two service API levels are provided within the same solution or domain:

•  a primary API level based on the preferred protocol
•  a secondary API level based on an alternative protocol

This allows the secondary protocol to be used whenever the primary protocol is deemed deficient or inappropriate. This solution furthermore allows services based on the secondary protocol to be promoted to the primary protocol when appropriate. Dual Protocols therefore provides a compromise that is essentially based on the standardization of two canonical protocols.

For example, when applying this pattern to a REST service-based solution, the REST services are typically classified as the primary service API because it is considered the preferred and default option. However, there may be performance requirements that cannot be adequately fulfilled by the REST services. In this case, the Dual Protocols pattern can be applied to provide a secondary service API via an alternative protocol, such as gRPC, GraphQL or Falcor.

 

 

 

 

 

 

 

 

 

A service providing a primary REST API and a secondary Web-capable RPC-based API.