What is the best way to implement an async REST method?

On 15 Jul 2014, at 17:21, Marc van Grootel wrote: > How would you implement an async REST pattern? I don't remember having > seen > anything that makes me do this using plain XQuery. Does this mean the > only > way to tackle this would be via Java and events maybe? > > I would post to a URL, this URL would accept the post and return a > temporary URL where I can check the status of my request, then once > it's > ready this temp URL will redirect me to the location of the real > resource. > That's the gist of the async REST pattern that I would like to > implement. > > What would be the best approach to experiment with this? > > --Marc

On 07/16/2014 09:58 AM, Michael Seiferle wrote: > Hi Marc, > > I actually think this could be done "manually" using RestXQ. > > You could maybe with something like this: > > client issues request to start a long running job: > 1) restxq/start/long-running-job -> returns job id 'Foo'

> > > Every n-seconds the client asks: > 2) restxq/is-job-running?job-id=Foo > -> either redirects to restxq/is-job-running?job-id=Foo iff job > 'Foo' is still running > -> or redirects to restxq/the-job-is-done iff job 'Foo' has > stopped running > > Obviously this kind of polling is neither an asynchronous nor the most > beautiful (yet, at the moment the only) way to do it. > > Personally I'd like to see support for > http://www.html5rocks.com/en/tutorials/websockets/basics/ Websockets, > this way RestXQ could notify the client once something is finished. > This would be true async communication and feel a lot better to deal > with. > >

> More opinions on this topic are very welcome :-) > > Best > Michael > > On 15 Jul 2014, at 17:21, Marc van Grootel wrote: > >> How would you implement an async REST pattern? I don't remember >> having seen >> anything that makes me do this using plain XQuery. Does this mean the >> only >> way to tackle this would be via Java and events maybe? >> >> I would post to a URL, this URL would accept the post and return a >> temporary URL where I can check the status of my request, then once it's >> ready this temp URL will redirect me to the location of the real >> resource. >> That's the gist of the async REST pattern that I would like to >> implement. >> >> What would be the best approach to experiment with this? >> >> --Marc >

On 16 July 2014 08:58, Michael Seiferle <ms at basex.org> wrote: > Hi Marc, > > I actually think this could be done "manually" using RestXQ. > > You could maybe with something like this: > > client issues request to start a long running job: > 1) restxq/start/long-running-job -> returns job id 'Foo' > > > Every n-seconds the client asks: > 2) restxq/is-job-running?job-id=Foo > -> either redirects to restxq/is-job-running?job-id=Foo iff job > 'Foo' is still running > -> or redirects to restxq/the-job-is-done iff job 'Foo' has > stopped running > > Obviously this kind of polling is neither an asynchronous nor the most > beautiful (yet, at the moment the only) way to do it. > > Personally I'd like to see support for http://www.html5rocks.com/en/ > tutorials/websockets/basics/ Websockets, this way RestXQ could notify the > client once something is finished. > This would be true async communication and feel a lot better to deal with. > > > More opinions on this topic are very welcome :-) > > Best > Michael > > > On 15 Jul 2014, at 17:21, Marc van Grootel wrote: > > How would you implement an async REST pattern? I don't remember having >> seen >> anything that makes me do this using plain XQuery. Does this mean the only >> way to tackle this would be via Java and events maybe? >> >> I would post to a URL, this URL would accept the post and return a >> temporary URL where I can check the status of my request, then once it's >> ready this temp URL will redirect me to the location of the real resource. >> That's the gist of the async REST pattern that I would like to implement. >> >> What would be the best approach to experiment with this? >> >> --Marc >> >

On 16 July 2014 09:55, Andy Bunce <bunce.andy at gmail.com> wrote: > Hi Micheal, > > I think there may be a problem with the idea of using RESTXQ. My > experience is that something stops requests after a minute or so, maybe it > is just the browser or maybe something related on the server (Jetty maxIdle > > <http://stackoverflow.com/questions/12421940/what-does-maxidletime-setting-mean-in-jetty> > time?) > > And while a web-socket interface would be great, I think asynchronous > execution is a core feature. > > - eXist has util:eval-async > <http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/util> > - 28msec has asynchronous-jobs > <http://www.28.io/documentation/latest/modules/parallelism/asynchronous-jobs> > - Marklogic has ModuleSpawn.html <http://modulespawn.html/> > > > /Andy > > > On 16 July 2014 08:58, Michael Seiferle <ms at basex.org> wrote: > >> Hi Marc, >> >> I actually think this could be done "manually" using RestXQ. >> >> You could maybe with something like this: >> >> client issues request to start a long running job: >> 1) restxq/start/long-running-job -> returns job id 'Foo' >> >> >> Every n-seconds the client asks: >> 2) restxq/is-job-running?job-id=Foo >> -> either redirects to restxq/is-job-running?job-id=Foo iff job >> 'Foo' is still running >> -> or redirects to restxq/the-job-is-done iff job 'Foo' has >> stopped running >> >> Obviously this kind of polling is neither an asynchronous nor the most >> beautiful (yet, at the moment the only) way to do it. >> >> Personally I'd like to see support for http://www.html5rocks.com/en/ >> tutorials/websockets/basics/ Websockets, this way RestXQ could notify >> the client once something is finished. >> This would be true async communication and feel a lot better to deal with. >> >> >> More opinions on this topic are very welcome :-) >> >> Best >> Michael >> >> >> On 15 Jul 2014, at 17:21, Marc van Grootel wrote: >> >> How would you implement an async REST pattern? I don't remember having >>> seen >>> anything that makes me do this using plain XQuery. Does this mean the >>> only >>> way to tackle this would be via Java and events maybe? >>> >>> I would post to a URL, this URL would accept the post and return a >>> temporary URL where I can check the status of my request, then once it's >>> ready this temp URL will redirect me to the location of the real >>> resource. >>> That's the gist of the async REST pattern that I would like to implement. >>> >>> What would be the best approach to experiment with this? >>> >>> --Marc >>> >> >

On Wed, Jul 16, 2014 at 10:58 AM, Andy Bunce <bunce.andy at gmail.com> wrote: > That marklogic link should have been: > http://docs.marklogic.com/xdmp:spawn > > > On 16 July 2014 09:55, Andy Bunce <bunce.andy at gmail.com> wrote: > >> Hi Micheal, >> >> I think there may be a problem with the idea of using RESTXQ. My >> experience is that something stops requests after a minute or so, maybe it >> is just the browser or maybe something related on the server (Jetty maxIdle >> >> <http://stackoverflow.com/questions/12421940/what-does-maxidletime-setting-mean-in-jetty> >> time?) >> >> And while a web-socket interface would be great, I think asynchronous >> execution is a core feature. >> >> - eXist has util:eval-async >> <http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/util> >> - 28msec has asynchronous-jobs >> <http://www.28.io/documentation/latest/modules/parallelism/asynchronous-jobs> >> - Marklogic has ModuleSpawn.html <http://modulespawn.html/> >> >> >> /Andy >> >> >> On 16 July 2014 08:58, Michael Seiferle <ms at basex.org> wrote: >> >>> Hi Marc, >>> >>> I actually think this could be done "manually" using RestXQ. >>> >>> You could maybe with something like this: >>> >>> client issues request to start a long running job: >>> 1) restxq/start/long-running-job -> returns job id 'Foo' >>> >>> >>> Every n-seconds the client asks: >>> 2) restxq/is-job-running?job-id=Foo >>> -> either redirects to restxq/is-job-running?job-id=Foo iff job >>> 'Foo' is still running >>> -> or redirects to restxq/the-job-is-done iff job 'Foo' has >>> stopped running >>> >>> Obviously this kind of polling is neither an asynchronous nor the most >>> beautiful (yet, at the moment the only) way to do it. >>> >>> Personally I'd like to see support for http://www.html5rocks.com/en/ >>> tutorials/websockets/basics/ Websockets, this way RestXQ could notify >>> the client once something is finished. >>> This would be true async communication and feel a lot better to deal >>> with. >>> >>> >>> More opinions on this topic are very welcome :-) >>> >>> Best >>> Michael >>> >>> >>> On 15 Jul 2014, at 17:21, Marc van Grootel wrote: >>> >>> How would you implement an async REST pattern? I don't remember having >>>> seen >>>> anything that makes me do this using plain XQuery. Does this mean the >>>> only >>>> way to tackle this would be via Java and events maybe? >>>> >>>> I would post to a URL, this URL would accept the post and return a >>>> temporary URL where I can check the status of my request, then once it's >>>> ready this temp URL will redirect me to the location of the real >>>> resource. >>>> That's the gist of the async REST pattern that I would like to >>>> implement. >>>> >>>> What would be the best approach to experiment with this? >>>> >>>> --Marc >>>> >>> >> >

On Wed, Jul 16, 2014 at 1:08 PM, Marc van Grootel < marc.van.grootel at gmail.com> wrote: > Exactly that would've been my followup question. We cannot spawn a call in > BaseX xquery, which is required in order to give a quick response but have > the processing continue. > > I've asked this also because I think this async pattern is an important > one for web services in general. > > > > > On Wed, Jul 16, 2014 at 10:58 AM, Andy Bunce <bunce.andy at gmail.com> wrote: > >> That marklogic link should have been: >> http://docs.marklogic.com/xdmp:spawn >> >> >> On 16 July 2014 09:55, Andy Bunce <bunce.andy at gmail.com> wrote: >> >>> Hi Micheal, >>> >>> I think there may be a problem with the idea of using RESTXQ. My >>> experience is that something stops requests after a minute or so, maybe it >>> is just the browser or maybe something related on the server (Jetty maxIdle >>> >>> <http://stackoverflow.com/questions/12421940/what-does-maxidletime-setting-mean-in-jetty> >>> time?) >>> >>> And while a web-socket interface would be great, I think asynchronous >>> execution is a core feature. >>> >>> - eXist has util:eval-async >>> <http://exist-db.org/exist/apps/fundocs/view.html?uri=http://exist-db.org/xquery/util> >>> - 28msec has asynchronous-jobs >>> <http://www.28.io/documentation/latest/modules/parallelism/asynchronous-jobs> >>> - Marklogic has ModuleSpawn.html <http://modulespawn.html/> >>> >>> >>> /Andy >>> >>> >>> On 16 July 2014 08:58, Michael Seiferle <ms at basex.org> wrote: >>> >>>> Hi Marc, >>>> >>>> I actually think this could be done "manually" using RestXQ. >>>> >>>> You could maybe with something like this: >>>> >>>> client issues request to start a long running job: >>>> 1) restxq/start/long-running-job -> returns job id 'Foo' >>>> >>>> >>>> Every n-seconds the client asks: >>>> 2) restxq/is-job-running?job-id=Foo >>>> -> either redirects to restxq/is-job-running?job-id=Foo iff >>>> job 'Foo' is still running >>>> -> or redirects to restxq/the-job-is-done iff job 'Foo' has >>>> stopped running >>>> >>>> Obviously this kind of polling is neither an asynchronous nor the most >>>> beautiful (yet, at the moment the only) way to do it. >>>> >>>> Personally I'd like to see support for http://www.html5rocks.com/en/ >>>> tutorials/websockets/basics/ Websockets, this way RestXQ could notify >>>> the client once something is finished. >>>> This would be true async communication and feel a lot better to deal >>>> with. >>>> >>>> >>>> More opinions on this topic are very welcome :-) >>>> >>>> Best >>>> Michael >>>> >>>> >>>> On 15 Jul 2014, at 17:21, Marc van Grootel wrote: >>>> >>>> How would you implement an async REST pattern? I don't remember having >>>>> seen >>>>> anything that makes me do this using plain XQuery. Does this mean the >>>>> only >>>>> way to tackle this would be via Java and events maybe? >>>>> >>>>> I would post to a URL, this URL would accept the post and return a >>>>> temporary URL where I can check the status of my request, then once >>>>> it's >>>>> ready this temp URL will redirect me to the location of the real >>>>> resource. >>>>> That's the gist of the async REST pattern that I would like to >>>>> implement. >>>>> >>>>> What would be the best approach to experiment with this? >>>>> >>>>> --Marc >>>>> >>>> >>> >> > > > -- > --Marc >

On Wed, Jul 16, 2014 at 1:40 PM, Marc van Grootel <marc.van.grootel at gmail.com> wrote: > Although a plain spawn would already be helpful, I think the 28msec > implementation is much more than this, with queues and all. Surprises me > that MarkLogic doesn't have other concurrency/async mechanisms than this? > Eventually I would love to see something like the mechanisms that are > available in Clojure or Go. Some articles > http://www.infoq.com/news/2013/07/core-async and > http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html > Obviously this goes far beyond spawning a query but a man can dream right > ;-) > > > On Wed, Jul 16, 2014 at 1:08 PM, Marc van Grootel > <marc.van.grootel at gmail.com> wrote: >> >> Exactly that would've been my followup question. We cannot spawn a call in >> BaseX xquery, which is required in order to give a quick response but have >> the processing continue. >> >> I've asked this also because I think this async pattern is an important >> one for web services in general. >> >> >> >> >> On Wed, Jul 16, 2014 at 10:58 AM, Andy Bunce <bunce.andy at gmail.com> wrote: >>> >>> That marklogic link should have been: >>> http://docs.marklogic.com/xdmp:spawn >>> >>> >>> On 16 July 2014 09:55, Andy Bunce <bunce.andy at gmail.com> wrote: >>>> >>>> Hi Micheal, >>>> >>>> I think there may be a problem with the idea of using RESTXQ. My >>>> experience is that something stops requests after a minute or so, maybe it >>>> is just the browser or maybe something related on the server (Jetty maxIdle >>>> time?) >>>> >>>> And while a web-socket interface would be great, I think asynchronous >>>> execution is a core feature. >>>> >>>> eXist has util:eval-async >>>> 28msec has asynchronous-jobs >>>> Marklogic has ModuleSpawn.html >>>> >>>> >>>> /Andy >>>> >>>> >>>> On 16 July 2014 08:58, Michael Seiferle <ms at basex.org> wrote: >>>>> >>>>> Hi Marc, >>>>> >>>>> I actually think this could be done "manually" using RestXQ. >>>>> >>>>> You could maybe with something like this: >>>>> >>>>> client issues request to start a long running job: >>>>> 1) restxq/start/long-running-job -> returns job id 'Foo' >>>>> >>>>> >>>>> Every n-seconds the client asks: >>>>> 2) restxq/is-job-running?job-id=Foo >>>>> -> either redirects to restxq/is-job-running?job-id=Foo iff job >>>>> 'Foo' is still running >>>>> -> or redirects to restxq/the-job-is-done iff job 'Foo' has >>>>> stopped running >>>>> >>>>> Obviously this kind of polling is neither an asynchronous nor the most >>>>> beautiful (yet, at the moment the only) way to do it. >>>>> >>>>> Personally I'd like to see support for >>>>> http://www.html5rocks.com/en/tutorials/websockets/basics/ Websockets, this >>>>> way RestXQ could notify the client once something is finished. >>>>> This would be true async communication and feel a lot better to deal >>>>> with. >>>>> >>>>> >>>>> More opinions on this topic are very welcome :-) >>>>> >>>>> Best >>>>> Michael >>>>> >>>>> >>>>> On 15 Jul 2014, at 17:21, Marc van Grootel wrote: >>>>> >>>>>> How would you implement an async REST pattern? I don't remember having >>>>>> seen >>>>>> anything that makes me do this using plain XQuery. Does this mean the >>>>>> only >>>>>> way to tackle this would be via Java and events maybe? >>>>>> >>>>>> I would post to a URL, this URL would accept the post and return a >>>>>> temporary URL where I can check the status of my request, then once >>>>>> it's >>>>>> ready this temp URL will redirect me to the location of the real >>>>>> resource. >>>>>> That's the gist of the async REST pattern that I would like to >>>>>> implement. >>>>>> >>>>>> What would be the best approach to experiment with this? >>>>>> >>>>>> --Marc >>>> >>>> >>> >> >> >> >> -- >> --Marc > > > > > -- > --Marc

On Wed, Jul 16, 2014 at 1:50 PM, Christian Grün <christian.gruen at gmail.com> wrote: > ...thanks a lot for your suggestions. Feel free to continue the > discussion, and we'll do our best to find out how your ideas can be > aligned with our architecture! > > > On Wed, Jul 16, 2014 at 1:40 PM, Marc van Grootel > <marc.van.grootel at gmail.com> wrote: >> Although a plain spawn would already be helpful, I think the 28msec >> implementation is much more than this, with queues and all. Surprises me >> that MarkLogic doesn't have other concurrency/async mechanisms than this? >> Eventually I would love to see something like the mechanisms that are >> available in Clojure or Go. Some articles >> http://www.infoq.com/news/2013/07/core-async and >> http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html >> Obviously this goes far beyond spawning a query but a man can dream right >> ;-) >> >> >> On Wed, Jul 16, 2014 at 1:08 PM, Marc van Grootel >> <marc.van.grootel at gmail.com> wrote: >>> >>> Exactly that would've been my followup question. We cannot spawn a call in >>> BaseX xquery, which is required in order to give a quick response but have >>> the processing continue. >>> >>> I've asked this also because I think this async pattern is an important >>> one for web services in general. >>> >>> >>> >>> >>> On Wed, Jul 16, 2014 at 10:58 AM, Andy Bunce <bunce.andy at gmail.com> wrote: >>>> >>>> That marklogic link should have been: >>>> http://docs.marklogic.com/xdmp:spawn >>>> >>>> >>>> On 16 July 2014 09:55, Andy Bunce <bunce.andy at gmail.com> wrote: >>>>> >>>>> Hi Micheal, >>>>> >>>>> I think there may be a problem with the idea of using RESTXQ. My >>>>> experience is that something stops requests after a minute or so, maybe it >>>>> is just the browser or maybe something related on the server (Jetty maxIdle >>>>> time?) >>>>> >>>>> And while a web-socket interface would be great, I think asynchronous >>>>> execution is a core feature. >>>>> >>>>> eXist has util:eval-async >>>>> 28msec has asynchronous-jobs >>>>> Marklogic has ModuleSpawn.html >>>>> >>>>> >>>>> /Andy >>>>> >>>>> >>>>> On 16 July 2014 08:58, Michael Seiferle <ms at basex.org> wrote: >>>>>> >>>>>> Hi Marc, >>>>>> >>>>>> I actually think this could be done "manually" using RestXQ. >>>>>> >>>>>> You could maybe with something like this: >>>>>> >>>>>> client issues request to start a long running job: >>>>>> 1) restxq/start/long-running-job -> returns job id 'Foo' >>>>>> >>>>>> >>>>>> Every n-seconds the client asks: >>>>>> 2) restxq/is-job-running?job-id=Foo >>>>>> -> either redirects to restxq/is-job-running?job-id=Foo iff job >>>>>> 'Foo' is still running >>>>>> -> or redirects to restxq/the-job-is-done iff job 'Foo' has >>>>>> stopped running >>>>>> >>>>>> Obviously this kind of polling is neither an asynchronous nor the most >>>>>> beautiful (yet, at the moment the only) way to do it. >>>>>> >>>>>> Personally I'd like to see support for >>>>>> http://www.html5rocks.com/en/tutorials/websockets/basics/ Websockets, this >>>>>> way RestXQ could notify the client once something is finished. >>>>>> This would be true async communication and feel a lot better to deal >>>>>> with. >>>>>> >>>>>> >>>>>> More opinions on this topic are very welcome :-) >>>>>> >>>>>> Best >>>>>> Michael >>>>>> >>>>>> >>>>>> On 15 Jul 2014, at 17:21, Marc van Grootel wrote: >>>>>> >>>>>>> How would you implement an async REST pattern? I don't remember having >>>>>>> seen >>>>>>> anything that makes me do this using plain XQuery. Does this mean the >>>>>>> only >>>>>>> way to tackle this would be via Java and events maybe? >>>>>>> >>>>>>> I would post to a URL, this URL would accept the post and return a >>>>>>> temporary URL where I can check the status of my request, then once >>>>>>> it's >>>>>>> ready this temp URL will redirect me to the location of the real >>>>>>> resource. >>>>>>> That's the gist of the async REST pattern that I would like to >>>>>>> implement. >>>>>>> >>>>>>> What would be the best approach to experiment with this? >>>>>>> >>>>>>> --Marc >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> --Marc >> >> >> >> >> -- >> --Marc

On Fri, Sep 12, 2014 at 6:26 PM, Christian Grün <christian.gruen at gmail.com> wrote: > Some time has passed since asynchronous REST communication has been > discussed on this list. I am afraid we cannot provide any solution so > far, but I added the requirement to our issue tracker [1]. Any edits > are welcome. > > Christian > > [1] https://github.com/BaseXdb/basex/issues/989 > > > On Wed, Jul 16, 2014 at 1:50 PM, Christian Grün > <christian.gruen at gmail.com> wrote: >> ...thanks a lot for your suggestions. Feel free to continue the >> discussion, and we'll do our best to find out how your ideas can be >> aligned with our architecture! >> >> >> On Wed, Jul 16, 2014 at 1:40 PM, Marc van Grootel >> <marc.van.grootel at gmail.com> wrote: >>> Although a plain spawn would already be helpful, I think the 28msec >>> implementation is much more than this, with queues and all. Surprises me >>> that MarkLogic doesn't have other concurrency/async mechanisms than this? >>> Eventually I would love to see something like the mechanisms that are >>> available in Clojure or Go. Some articles >>> http://www.infoq.com/news/2013/07/core-async and >>> http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html >>> Obviously this goes far beyond spawning a query but a man can dream right >>> ;-) >>> >>> >>> On Wed, Jul 16, 2014 at 1:08 PM, Marc van Grootel >>> <marc.van.grootel at gmail.com> wrote: >>>> >>>> Exactly that would've been my followup question. We cannot spawn a call in >>>> BaseX xquery, which is required in order to give a quick response but have >>>> the processing continue. >>>> >>>> I've asked this also because I think this async pattern is an important >>>> one for web services in general. >>>> >>>> >>>> >>>> >>>> On Wed, Jul 16, 2014 at 10:58 AM, Andy Bunce <bunce.andy at gmail.com> wrote: >>>>> >>>>> That marklogic link should have been: >>>>> http://docs.marklogic.com/xdmp:spawn >>>>> >>>>> >>>>> On 16 July 2014 09:55, Andy Bunce <bunce.andy at gmail.com> wrote: >>>>>> >>>>>> Hi Micheal, >>>>>> >>>>>> I think there may be a problem with the idea of using RESTXQ. My >>>>>> experience is that something stops requests after a minute or so, maybe it >>>>>> is just the browser or maybe something related on the server (Jetty maxIdle >>>>>> time?) >>>>>> >>>>>> And while a web-socket interface would be great, I think asynchronous >>>>>> execution is a core feature. >>>>>> >>>>>> eXist has util:eval-async >>>>>> 28msec has asynchronous-jobs >>>>>> Marklogic has ModuleSpawn.html >>>>>> >>>>>> >>>>>> /Andy >>>>>> >>>>>> >>>>>> On 16 July 2014 08:58, Michael Seiferle <ms at basex.org> wrote: >>>>>>> >>>>>>> Hi Marc, >>>>>>> >>>>>>> I actually think this could be done "manually" using RestXQ. >>>>>>> >>>>>>> You could maybe with something like this: >>>>>>> >>>>>>> client issues request to start a long running job: >>>>>>> 1) restxq/start/long-running-job -> returns job id 'Foo' >>>>>>> >>>>>>> >>>>>>> Every n-seconds the client asks: >>>>>>> 2) restxq/is-job-running?job-id=Foo >>>>>>> -> either redirects to restxq/is-job-running?job-id=Foo iff job >>>>>>> 'Foo' is still running >>>>>>> -> or redirects to restxq/the-job-is-done iff job 'Foo' has >>>>>>> stopped running >>>>>>> >>>>>>> Obviously this kind of polling is neither an asynchronous nor the most >>>>>>> beautiful (yet, at the moment the only) way to do it. >>>>>>> >>>>>>> Personally I'd like to see support for >>>>>>> http://www.html5rocks.com/en/tutorials/websockets/basics/ Websockets, this >>>>>>> way RestXQ could notify the client once something is finished. >>>>>>> This would be true async communication and feel a lot better to deal >>>>>>> with. >>>>>>> >>>>>>> >>>>>>> More opinions on this topic are very welcome :-) >>>>>>> >>>>>>> Best >>>>>>> Michael >>>>>>> >>>>>>> >>>>>>> On 15 Jul 2014, at 17:21, Marc van Grootel wrote: >>>>>>> >>>>>>>> How would you implement an async REST pattern? I don't remember having >>>>>>>> seen >>>>>>>> anything that makes me do this using plain XQuery. Does this mean the >>>>>>>> only >>>>>>>> way to tackle this would be via Java and events maybe? >>>>>>>> >>>>>>>> I would post to a URL, this URL would accept the post and return a >>>>>>>> temporary URL where I can check the status of my request, then once >>>>>>>> it's >>>>>>>> ready this temp URL will redirect me to the location of the real >>>>>>>> resource. >>>>>>>> That's the gist of the async REST pattern that I would like to >>>>>>>> implement. >>>>>>>> >>>>>>>> What would be the best approach to experiment with this? >>>>>>>> >>>>>>>> --Marc >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> --Marc >>> >>> >>> >>> >>> -- >>> --Marc