camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gonzalo diethelm <>
Subject RE: Service architecture
Date Tue, 29 Mar 2011 11:59:55 GMT
> > 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("${}")
> .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

View raw message