...
- Using 'POST' instead of 'GET' for message retrieval
A 'POST' API call for retrieval of messages aligns with HTTP semantics, especially considering the nature of Match Connect. In line with HTTP semantics and RESTful best practices, 'GET' requests should per definition be cacheable. In Match Connect message retrieval triggers a mutation, because messages are no longer available after retrieval. Therefore, the information in Match Connect is non-cacheable.
The 'POST' method better reflects the intention of performing a server-side operation and helps avoid unintended caching of mutable operations, enhancing the overall robustness and correctness of Match Connect.
Additional information about RESTful best practices can be found here.
Additional information about HTTP semantics can be found here.
2.4.4 Generic message flow for Connect messages
For all ...
| PlantUML Macro | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
participant "Patient Registry" as PR
control "Match-Connect" as MC
control "Search & Match\nService" as SM
participant "Donor Registry" as DR
skinparam SequenceMessageAlign center
skinparam dpi 92
== Making Request ==
PR -[#dodgerblue]> DR : Send message
MC -> PR : 400 Bad Request (optional)
MC -> PR : 200 OK (possibly with warnings)
PR -> MC : Check not-picked up messages
MC -> PR : 200 OK - Array of messages not yet delivered
== Getting Response ==
DR -[#dodgerblue]> PR : Message response (ack, reject, warning) \nshould always include messageId of referring message
|
2.4.5 Automatically generated and manually curated Swagger
The use of both an automatically generated and manually curated Swagger serves a dual purpose.
...
Together, these two approaches provide important information about technical accuracy and communication about the development of Match Connect.
2.4.
...
6 Message storage retention policies
Messages sent using the Connect API have the following retention policies applied:
...