Home > REST Service vs. Non-REST Service Contracts > REST Service Contracts and Late Binding

REST Service Contracts and Late Binding

Within the context of REST service contracts, late binding occurs when a service consumer discovers a resource identifier that it uses at runtime rather than having been designed to use the resource identifier at design time. By taking advantage of opportunities to apply late binding, we can loosen the coupling between services while simplifying and increasing the flexibility of service contracts. REST service contracts can often be designed to minimize published information (and support late binding) by removing select resource identifier details.

Consider the following service capability used to retrieve a manifest for a shipment:

GET http://shipping/manifest/{id}: application/parts-list+xml

This statement implies that the core service logic might invoke something along the lines of a getManifest(id) function within the core service logic API, which would require the consumer logic to be designed to specifically provide this ID value with each invocation.

As an alternative, we design a looser coupled relationship between the service and its consumers by allowing the manifest ID to be "discovered" with its complete resource identifier at runtime.

So, upon receiving a resource identifier statement like this:

http://shipping/manifest/34

...the service consumer could obtain the ID value would be to parse it from this statement, or simply forward the entire resource identifier "as is" to the REST service.

With this type of flexibility, the REST service capability content in the service contract can be reduced to:

GET {+manifest}: application/parts-list+xml

...where the plus ("+") symbol is used to indicate that the service capability accepts a range of resource identifiers of "type" manifest.

NOTE

The use of the plus ("+") symbol for this purpose originates from the RFC6570 URI Template industry standard, where {+some-identifier} is considered a parameter that makes up part of the structure of the URL.

There are other types of resource that can be more considered properties of a parent entity rather than entities in their own right. These can pose a challenge when attempting to streamline the level of resource identifier abstraction, because we need to start trading off between the amount of knowledge that consumers have about the service contract and the number of officially registered relationship types that exist as part of the uniform contract.

For example:

GET http://customer/customer/{id}/address: application/vcard+xml

...could be optimized either as:

GET {+customer}/address: application/vcard+xml

...or as:

GET {+address}: application/vcard+xml

...where the address URL can be found by querying a known customer resource.

The first of these alternatives requires less complex composition logic and fewer messages than the second. Despite this, the second option may be more desirable. The reasons for this are multi-layered and do not necessarily start with a normalized service inventory in mind:

  • The consumer may need to interact with a different service that has a slightly different resource identifier structure. For example, a future version of the service or a Customer service from another service inventory that shares a common contract with this Customer service.
  • The service may actually wish to delegate this service capability to a dedicated Address service (either now or in the future), rather than handle address-related requests itself.

One other possibility to increase the level of abstraction of a service contact is to rely on the uniform contract to define parts of the contract. For example, if a customer resource contains and "address" hyperlink to the address resource, then sufficient information may be present in the customer media type to understand how to access the related address resource. In theory we could remove the address resource from the published service contract because any consumer would need to access the customer resource and could determine that the related address resource exists without the need for an explicit service contract entry.