Lightweight Endpoint (Balasubramanian, Carlyle, Pautasso)
How can lightweight units of business logic be positioned as effective reusable enterprise resources?
A service consumer that requires access to business entity information (such as data about an invoice) needs to maintain two identifiers: one for the service and another for the invoice itself. The business entity identifier may be unique only within the scope of the service contract, and the service consumer may be limited to using unnecessarily coarse-grained service capabilities pre-defined as part of the published service contract. This can result in wasteful data exchange and consumer-side processing.
Expose data and functionality associated with business entities as a series of granular, lightweight endpoints. Allow consumers to target those endpoints in order to optimize data exchange and consumer-side processing.
A service contract needs to expose service capabilities that offer a range of functional granularity. Each of these “lightweight” capabilities is associated with a business entity.
Finer grained service capabilities can result in verbose resource identifiers that may impose a greater governance burden.
Applying this pattern can lead to resource overlap in order for multiple service capabilities to offer access at multiple levels of granularity. For example, an invoice and properties of the invoice can be exposed as separate resources, even though they refer to a common set of underlying data or functionality.
Greater effort may be required when applying Service Façade, when the façade relates functionality associated with granular resources to core service logic.