...
- Using the endpoint: availableMessagesAll - Retrieve an array of all the messages that are ready to be downloaded, including message content (OPTIONAL, MAY NOT BE IMPLEMENTED)
This endpoint allows end users to retrieve an array of all messages ready to be downloaded, including their content. This would allow a registry to call one single endpoint to collect all messages.
Limitations:
This option does not work for all applications/tooling, like defining custom API connectors in the 365 PowerPlatform. In those cases the same static structure for all call responses on a specific endpoint is not only implementing best practices (IBP), but also required.
2.4.3 RESTful best practices
In the development of Match Connect, we have adhered to RESTful best practices to ensure optimal performance and maintainability.
The design-choices for Match Connect prioritize simplicity, scalability and standardization.
Justification for some of these decisions are further explained below:
- 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.