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.
