Service API Patterns, Protocols, Coupling Types, Metrics > Service API Design Patterns > Canonical Schema

 

Canonical Schema

How can services be designed to avoid data model transformation?

For a service to send or receive data, it needs to know in advance exactly how that data will be organized and structured. When different services are delivered by different project teams, each team may decide to structure an invoice data model in a different way. When those services need to exchange invoice data at a later point in time, they will not be compatible and will require the application of the Data Model Transformation pattern to convert one invoice document structure into another. This generally introduces the need to design and develop a custom transformation layer consisting of mapping logic and rules that resolve differences between disparate schemas. This logic often needs to be carried out every time data needs to be exchanged, and is therefore considered undesirable.

With the application of the Canonical Schema pattern, the need for Data Model Transformation pattern can be avoided by ensuring that service APIs are designed with compatible schemas. This is achieved by applying design standards to the schemas associated with the service APIs. Once standardized schemas are in place, this pattern is realized via a formal process through which service APIs are designed, which ensures consistent application of design standards.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A Web service and REST service share a canonical XML schema, while two REST services share a canonical JSON schema.