dido:99_annexes:annex-b-terms-and-definitions:r:rest

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
dido:99_annexes:annex-b-terms-and-definitions:r:rest [2026/07/11 11:14] – removed - external edit (Unknown date) 127.0.0.1dido:99_annexes:annex-b-terms-and-definitions:r:rest [2026/08/04 07:09] (current) – ↷ Links adapted because of a move operation nick_dido
Line 1: Line 1:
 +====== Representational State Transfer (REST) ======
 +
 +[[dido:99_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]]
 +
 +===== Discussion =====
 +
 +Representational State Transfer (REST) is an implementation interface style that exposes resources through a uniform set of operations and resource identifiers.
 +
 +A REST interface typically uses resource-oriented interaction, request and response messages, representations of resource state, stateless interaction, and standard protocol mechanisms. In common web implementations, REST interfaces often use HTTP methods, URIs, headers, status codes, and payload representations such as JSON or XML.
 +
 +In the FX Demo [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]], REST references identify possible implementation mechanisms. REST does not define the logical meaning of a [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]], data structure, policy decision, release package, or runtime plane.
 +
 +A REST interface can realize, expose, or support a logical communication pattern selected by an implementation profile. The logical architecture remains independent of REST resource design, URI design, HTTP method selection, payload format, authentication mechanism, deployment boundary, and service implementation.
 +
 +===== Definition =====
 +
 +//implementation interface style that exposes resources through a uniform set of operations and resource identifiers//
 +
 +===== Source =====
 +
 +Generalised from common software architecture usage and specialized for use in the FX Demo [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]].
 +
 +===== Note =====
 +
 +REST is not a logical [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:a:api|Application Programming Interface (API)]], data structure, message, runtime plane, deployment artifact, or policy mechanism. A REST API may implement or expose an architectural interaction selected by an implementation profile.
 +
 +===== Example =====
 +
 +A later implementation profile may expose an FX Release Package through a REST resource, while the logical architecture defines the release interaction through the FX Release Package Endpoint.