> > One thing I have not been able to figure out is how to expose all these
> CRUD services over jetty. Just as an example, let's say I will handle
> account objects and will want to support three actions on them:
> >
> > GET /account/{id} => retrieve that account
> > PUT /account/{id}/balance/{bal} => update that account's balance
> > DELETE /account/{id} => delete that account
> >
> > How many end points do I need to expose with a from("jetty")? If it is
> only one endpoint for all actions (which would be great), how do I route
> to the proper bean method given the HTTP method and the set of parameters
> I received? If it is one endpoint for each action, how do I specify the
> endpoints so that they are differentiated by their HTTP method and URL
> parameters?
>
> I don't know, if this /account/{id} stuff works with jetty, but it works
> well with RESTLET (wich starts an internal http server and is a REST
> component by default). I would create for all operations a single
> endpoint. They could look like:
Great, this works. And I guess you meant that you would create one endpoint for
each operation, right? Oh, and this only works with restlet v1, right? I was
unable to make Camel work with restlet v2.
> from("restlet:http://localhost:9080/account/{id}?restletMethod=get";)
> .setBody("${header.id}")
> .to("bean://myService?method=get");
The only weird thing I am seeing is warnings such as:
com.noelios.restlet.http.HttpConverter addAdditionalHeaders
WARNING: Addition of the standard header "User-Agent" is not allowed.
Please use the Restlet API instead.
Any ideas?
> > I am leaning more towards using pure Spring (REST / JMS templates) to
> invoke the services; it seems more natural to me and I think the
> developers would find it an easier path.
>
> I don't see why this should be easier - but okay :)
It is just that I would like the team building the clients not to think in
terms of a service bus or integration, but in terms of simple RPC.
> > I definitely will. Thanks for clarifying this for me; this area is where
> my expertise is the least (close to zero), and to my newbie eyes OSGi
> seems "too good to be true".
>
> I'm not sure if your services have a good granularity to deploy each of
> them as a single application in an OSGi container, because there is some
> little overhead to make them ready for OSGi.
I guess some testing (on my part) is called for.
--
Gonzalo Diethelm
