Hi Andrei
On 22/07/13 12:50, Andrei Shakirin wrote:
Hi Sergei,
so I can only think of having a single master RS resource which will listen on
say "/services/rs", and will support both GET & POST and then it will delegate
to the right bundle which actually implements read or write - these two
bundles won't act as RS resources on their own, will simply be the 'executors'
Does it work ?
Yep, it should work. Let see how to process start and stop both executors
correctly, that user has impression that appropriate service is not available.
But generally it is a solution.
I guess if we have two different 'executor' bundles then the master one
will use ServiceTracker and ServiceListener and report 404 till both
bundles have (re)started.
We'd have the same issue of dealing with the the temp unavailability
even without the master bundle. In fact it can allow to respond say with
503 (or may be 307 somehow) when we know that one of the executors is
being reloaded, etc...
Cheers, Sergey
Regards,
Andrei.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Montag, 22. Juli 2013 12:39
To: [email protected]
Subject: Re: Two bundle for GET and POST for the same resource URL
Hi Andrei
On 22/07/13 11:29, Andrei Shakirin wrote:
Hi Sergei,
Thanks for your answer, not sure that I described the issue clear
enough :)
The question was is it technically possible (for example in Karaf), that two
bundles expose the same resource URL, but one bundle provides
implementation for GET verb and second bundle - for POST/PUT verbs?
Is there any solution for resource URL conflict between different bundles?
Sorry, I see now.
To be honest we probably need to introduce a master bundle here which will
be aware of the other 2 bundles and coordinate the dispatching to either of
those 2 bundles, we can not have 2 bundles with the endpoints having the
same base address,
so I can only think of having a single master RS resource which will listen on
say "/services/rs", and will support both GET & POST and then it will delegate
to the right bundle which actually implements read or write - these two
bundles won't act as RS resources on their own, will simply be the 'executors'
Does it work ?
Cheers, Sergey
Regards,
Andrei.
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Montag, 22. Juli 2013 11:55
To: [email protected]
Subject: Re: Two bundle for GET and POST for the same resource URL
Hi
On 22/07/13 10:48, Andrei Shakirin wrote:
Hi,
A question regarding REST design.
Is it technically possible to provide two OSGi bundles for the same
resource
URL, that one bundle exposes GET method and other POST method for
the
same resource?
Use case read and write access to the resource must be spitted to
different OSGi services (bundles). But from design view is undesired
to have different resource URLs.
Sure, typically a 'container' resource can support both GET & POST,
example, "/customers", GET will return a list of customers, POST will
add a new customer. If we talk about a single resource, say '/customer'
than a purer way is to have PUT instead of POST, but if working with
PUT is difficult then POST would do IMHO
Cheers, Sergey
Regards,
Andrei.
