On 26 May 2011 12:57, Jim Talbut <jtal...@spudsoft.co.uk> wrote:
> On 26/05/2011 11:51, James Strachan wrote:
>>
>> Also we don't need to rewrite camel-web just to provide support for
>> multiple contexts; all thats really required is one or two resource
>> beans using the OSGi or JMX API to discover the contexts and a
>> template page or two and multiple contexts could be supported very
>> easily. One of the big reasons I chose JAXRS is its trivial to extend
>> a web application in a highly modular way; so folks can easily drop in
>> different UIs if they want. Plus its easy to put different facades on
>> top of the camel-web; e.g. you could just interact with its REST API
>> and put any UI you like on top of it.
>
> James,
>
> The complexity here is that we have two choices for the API:
> 1. My preferred option is to change all the existing REST URLs so that they
> have the camel context name first.
Yeah. How about /camel/{contextId}/routes/{routeId}
I picked /camel as the root URI for all contexts so that we can then
mix this web app with other web apps showing other things without
clashing.
> Hence this "http://localhost:9080/camelweb/routes/route2"; becomes this
> "http://localhost:9080/camelweb/contexts/169-camel-7/routes/route2";
> This is obviously a breaking change for any existing REST clients and
> affects the existing templates too (just in that some of the stuff displayed
> by default is not valid without a context).
> 2. The alternative, which is less code and less breaking, is to have a
> concept of the current default came context.
> That would leave all the existing REST URLs alone, but would be stateful and
> thus yucky.
> Unless someone shouts I'm going to do the first, but it's a bigger change.
> Still not too big, I'd have done it by now if my disc heads hadn't nose
> dived into the platter and camel trunk had fewer build/test breaks.
It shouldn't break terribly much to be honest; the templates are
associated with the resource bean types, not their URIs so you can
usually refactor the URI templates and move or add resource beans to
different places in the URI space without too much problem (unless
folks have written their own REST clients that is). We just have to
double check the links in the HTML are OK - but typically we try to
use relative URIs so hopefully not too many of those will break.
--
James
-------
FuseSource
Email: ja...@fusesource.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
