Context Representation

_{Published: 26 January 2024}

Known Uses

The Context Representation pattern is a less obvious one. Context information such as authentication and authorization, is frequently managed by API gateway intermediaries using standardized and generic methods. This context information is often delegated to the underlying protocol (e.g., through HTTP headers), and an explicit Context Representation in the request or response payload is infrequent. Nevertheless, the book rightly emphasizes that, advocating for protocol independence, this pattern offers an alternative approach to relying solely on standard headers and the header extension capabilities of the networking protocol.

• In the WSDL/SOAP era, this pattern was actively used within the Dutch Energy sector. A standard business document header (included as part of the XML payload) was defined, drawing from and inspired by industry standards such as UN/CEFACT Standard Business Document Header.
• OAGIS ApplicationArea: This business document header contains context information like: CreationTimestamp, MessageID, CorrelationID, MessageVersion, SenderID, and so on.

Another use case is NL GOV profile for CloudEvents. This is the Dutch government profile based on the CloudEvents 1.0.1 specification. The CloudEvents specification is geared more towards generic use, and in the Netherlands, we want to add a number of requirements for the Dutch situation with the goal to agree on how to use the CloudEvents specification. In the CloudEvents specification, context attributes are standardized metadata fields that provide essential information about the event itself. The core context attributes defined in CloudEvents include id, source, time, specversion, subject, datacontenttype and so on. These context attributes are typically bundled together as a structured set of metadata fields at the beginning of the event. They form a header-like structure that provides essential information about the event itself. However, they might not always be physically located at the very beginning of the event payload, depending on the transport or serialization format being used.

Discussion Input

This pattern requires additional attention, particularly as we pursue a more event-driven strategy in both the government and energy sectors. AsyncAPI is gaining more importance, and it brings integration camps (synchronous and asynchronous communication) together. New integration technologies and protocols will be introduced, ensuring the sustained relevance of this pattern in the future. To increase operability, allowing more API clients to connect, it can be beneficial to offer APIs in protocols and architectural styles other than REST/JSON. So a protocol agnostic approach is needed. The Context Representation pattern aims to help by normalizing payloads and metadata that producers and consumers can use to ensure logic does not break when the protocol changes. To be continued 😊!