...
| # | Issue | Decision | Notes/Jira | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | What topic to use? proposed ncmp-async-xxx | Topic provide by client?! | |||||||||
| 2 | Are adding a new REST endpoint for async or modifying an existing endpoint? | To facilitate asynchronous requests to DMI we will need to either create a new endpoint or modify existing endpoint to include /async flag. The second solution may not be backwards compatible. However creating a new endpoint solely for a flag is also not ideal. We could add async to list of options (but this might interfere with the purpose of /options. Additionally, considered adding a new endpoint for async which simply re-routes the response to the original endpoint while adding the logic for OK response to the client. However, would this lead to a change in the schema? If so, would this be backwards compatible?
| |||||||||
| 3 | Agree URL for async once #2 is clarified | ||||||||||
| 4 | Passthrough request need to be able to handle different response types (using accept header) but the async option would have a fixed and possibly different response type. | ||||||||||
| 5 | How many messages are we expecting at peak time? | ||||||||||
| 6 | Should we create a standalone app to demo or are tests sufficient? | ||||||||||
| 7 | Do we need to persist the generated requestID? | ||||||||||
| 8 | Will cps-temporal require the requestID? |
...