Service API Patterns, Protocols, Coupling Types, Metrics > Fundamental Service API Patterns > Decoupled Service API

 

Decoupled Service API

How can a service API be published independent of its implementation?

Services can be built using RPC-based or component-centric distributed development technologies. Although these development environments provide adequate platforms for building components as services, they usually require that the API be physically bound to the underlying service logic. This essentially requires that the service API be expressed via the same native technologies used to build the components. As a result, the utilization and evolution of services is inhibited because they can only be used by consumer programs compatible with their technology.

With the application of the Decoupled Service API pattern, the service API is created as a physically separate part of the overall service implementation, which decouples the API from the underlying service implementation to allow it to be independently designed and governed.

 

 

 

 

 

 

By decoupling the service API, the service logic implementation can be evolved without directly impacting service consumers. This can increase refactoring opportunities and the range of potential consumer programs.

A common risk associated with expressing service APIs following this pattern is the use of development tools to auto-generate of service API. This can result in a negative form of coupling know as implementation coupling (as explained in the Negative Service API Coupling Types section). This issue can be addressed by advocating the independent creation of a service API so that its content can also remain decoupled from any existing or future logic and resources it may be required to encapsulate.

The application of the Decoupled Service API pattern may be limited to service development environments that natively support physically independent APIs.