On Wed, Mar 24, 2010 at 5:57 PM, Luciano Resende <[email protected]> wrote: > 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 ?
It was about existing SCA services that you now want to expose as a REST endpoint so they wont have any JAX-RS annotations. > What is the difference between this > and the usage of Collection interface pattern that maps the HTTP > operations to specific method operations ? > I'm not sure, could you give an example of what the Collection interface pattern looks like? >> <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. > Sure, wireformat.json was just one example, having one that can do more based on headers sounds good. > 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 ? This bit I'm not sure about yet, requiring the implementation to have GET/PUT/etc operations doesn't seem perfect to me so i was think the operation selector could do more than that. But i think we should talk to the spec people, try a few things, see what works and what doesn't. > > 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... > Sure ok, how about we start a new HTTP binding for this based on the OASIS draft spec. ...ant
