Stream: implementers
Topic: Loopback url
Medi Harsini (Nov 17 2020 at 17:20):
Is there anyway that we add loopback/call back url into the any request, for example post /appointment which requires a bit of processing which then needs to inform the caller. This is differ from sync asynchronous type translations but merely a way that the resource update can be then fed back to the caller
Lloyd McKenzie (Nov 17 2020 at 17:24):
Typically there's either a "please store", which is a simple RESTful POST/PUT and the only information to be passed back is "what it stored, and if so, what's the URL".; or there's "please execute", which is generally handled using Task. The Task gets updated at various points to indicate process, and sometimes what comes back. It sounds like your use-case is the latter?
Medi Harsini (Nov 17 2020 at 19:10):
I’m thinking about subscription now, because my case can’t fit task really
Lloyd McKenzie (Nov 17 2020 at 19:46):
There are a whole bunch of approaches to using workflow (which is the process of saying "please execute") in the core spec. Most of them use Task because that's the only way to allow communicating yes or no and indicating progress. However, if you don't need to close the loop at all or the presumed answer is always "yes" (at in-band), there are other approaches that can work.
Medi Harsini (Nov 17 2020 at 22:35):
What would you suggest of the latter is the case
Lloyd McKenzie (Nov 17 2020 at 22:41):
Simplest would be the 'tag' approach where you post the 'request' and the filler eventually posts the 'event' with a basedOn link to the 'request'.
Michele Mottini (Nov 17 2020 at 22:47):
Use $process-message ?
Lloyd McKenzie (Nov 17 2020 at 22:47):
That's also possible, but it requires custom implementation on both sides.
Last updated: Apr 12 2022 at 19:14 UTC
