On Tue, Mar 23, 2010 at 12:03 AM, ant elder <[email protected]> wrote: > It seems harder than the EJB case because REST services don't have a > one-to-one mapping to arbitrary Java interfaces whereas EJB services > do. We could try to do something similar to what the old 1.x > binding.atom does but I don't think that works very well and we should > try to do something better for in Tuscany 2.x. I think there's two > types of scenarios we should look at supporting: > > 1) developing new REST services as part of an SCA application > 2) exposing existing SCA services as REST endpoints > > For (1), chances are if you're a Java programmer you'll want to use > JAX-RS, its a good API that people like and if you do any searching to > learn about Java and REST these days most doc is about JAX-RS. So it > would be good to support that and have it just work the way people are > expecting. Thats the approach I was suggesting in the earlier email > with adding support for SCA annotations in JAX-RS resources. >
+1, I agree that the future of rest is to be based on JAX-RS. > For (2), we need a way to take an arbitrary service and map each > operation to one of the REST operations (GET, POST, PUT, DELETE) and > configure its HTTP endpoint. That sounds like binding.http and using > the new wireformat and operation selectors that are available in the > latest OASIS specs. We may be able to come up with some pre-canned > wireformat and operation selectors that can do everything needed just > from SCDL configuration but i suspect a lot of the time that wont be > enough and there will need to be a way to call out to some user > provided code to do the mapping, eg something like: > Is this scenario, are you trying to cover the case where you don't have access to the application artifacts to properly set the necessary mapping annotations from JAX-RS ? What is the difference between this and the usage of Collection interface pattern that maps the HTTP operations to specific method operations ? > <binding.http> > <wireformat.json> > <operationselector.custom class="some.UserClass"/> > </binding.http> > > How does that sound? > About the wireFormat, I think there are two scenarios : - I want to always force a specific wireFormat, then configuring it on the composite is fine and wireformat.json seems ok - I want to make things flexible, based on how HTTP uses acceptHeaders to identify what type of payload it is expecting on the response, and for this I was thinking about having something more like <wireformat.httpAcceptHeader> and then do some magic using dataBinding or throwing somekind of HTTP error code back if format is not supported. Now, regarding the operationSelector, what did you have in mind with this custom one ? Mainly map HTTP operation to methods based on a convention over configuration pattern ? BTW, I've started prototyping something very basic support for this, on top of http binding we have today... let me know if you want to collaborate, and maybe i could get this going as a copy of the current binding to avoid any breakages... -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
