Hypermedia and Late Binding
Hypermedia is a broad term used to represent environments and resources related through the use of hyperlinks. The World Wide Web is a classic example of hypermedia. Given that the primary goal of REST architecture is to mirror the architecture of the Web, hypermedia results as a natural characteristic that can be leveraged to create relationships between resources.
These intrinsic relationships can help loosen the coupling between service consumers and REST services by enabling REST services to provide resources with hyperlinks to other resources (provided by the same or other REST services). The service consumer can receive these hyperlinks at runtime and act upon them. Although the service consumer would need to have been designed to look for and process a hyperlinked resource identifier, it would not have needed prior knowledge of the nature of the resource identifier, nor the location of the resource.
To demonstrate, let's revisit the interaction scenario we explored in the previous section. In this variation of the scenario, our service consumer has the following information prior to beginning its interaction with the REST services:
- the resource identifier for the invoice: /invoice/I001
- knowledge that the invoice will include a hyperlink to a customer record
- the resource identifier of the print queue to use for the label: /printer/OfficeLaser
Figure 1 - The service consumer interacts with the Invoice, Customer and Printer services at runtime. However, at design-time, the service consumer is only aware of the Invoice and Printer services. The interaction with the Customer service (highlighted in red) occurs as a result of a hyperlink provided by the Invoice service.
As illustrated in Figure 1, the service consumer begins by invoking the Invoice service using the invoice resource identifier, which points to a resource provided by the Invoice service. In order to retrieve data from this resource, the service consumer uses the GET method.
Upon receiving the requested invoice, the service consumer "discovers" an embedded hyperlink pointing to a required customer resource. The service consumer logic is designed such that it is able to follow the hyperlink to the invoice's customer record in order to extract the customer mailing address. Finally, the service consumer invokes the Printer service to add a document containing the customer address to the print queue.
The more loosely coupled the relationship between the service consumer and the Customer service are, the more flexible the overall service composition architecture will be because it is less likely that the service consumer will be impacted by change.
Here are some examples of changes or factors from which the service consumer can be protected:
- the Invoice and Customer services could be the same service initially and different services at a later point
- the Customer service could be further split up and refactored
- there may be one Customer service, or there may be many (for example, each individual customer might maintain their own Customer service to ensure contact information is completely up to date)
- the requested Customer resource identifier could change
Figure 2 further highlights where direct coupling does and does not exist among the resources involved in this interaction.
Figure 2 - The service consumer follows a hypermedia link to access a resource provided by the Customer service. The hypermedia link is provided to the service consumer by the Invoice service at runtime.
It is worth noting that aside from resource dynamically providing hyperlinks via HTTP messages, there are other means by which linked resource identifiers can be provided to service consumers in a loosely coupled manner.
- hyperlinks stored within configuration files that are loaded by the service consumer logic at startup
- resource identifiers input by human users via forms or command-line statements
Each of these is an example of hypermedia, or simply "linking".