On Fri, Aug 27, 2010 at 2:34 PM, ant elder <antel...@apache.org> wrote: > On Fri, Aug 27, 2010 at 6:40 PM, Luciano Resende <luckbr1...@gmail.com> wrote: > >> But, stepping back, > > Ok lets do that, so we've got the composite at > https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/hema/src/main/webapp/WEB-INF/web.composite > with component service HelloworldComponent/HelloworldService and the > service interface is: > > @Remotable > public interface HelloworldService { > String sayHello(String name); > } > > That works for bindings like sca, ws, rmi, etc, and now we want to > expose it as an http endpoint. We shouldn't need to add any > annotations or modify the service interface or impl. We need to encode > the operation name, the parameters, and perhaps the format to get the > response back in (eg xml or json perhaps). The operation name could be > part of the url, in this example theres a single string parameter so > using the url query parameters seems useful but if the parameters were > more complex you might want to use xml or json with an http post > request. >
+1, if you have a good solution for mapping HTTP Verbs to Service operations without any type of configuration, or convetion as in the Collection itnerface, please feel free to share. > So that would be things like an http get > http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello?name=petra, The problem with this is that there isn't a good way to find the parameter name at runtime, and that's why JAX-RS created such annotations to do the map (e.g QueryParam, etc) > or an http post > http://localhost:8080/sample-hema/HelloworldComponent/HelloworldService/sayHello > with a json or xml request body. And perhaps an accept header could > define the default for what type or response is returned eg xml or > json (or javascript too and then we wouldn't need the jsonp binding). > You mean, content-type on the post identifying that you are providing json or xml. Agree, but I think we should support both scenarios, a dynamic one and a "hard coded" one where the service will only output what is specified on the wireFormat. We probably need some enhancements on our databinding framework to better support mime types, and our rest binding does provide most of this trough the wink integration. > Does that all sound reasonable so far, if so we can then map that in > to what sca binding, wireformat and operationSelector elements could > look like. > Are you mostly concerned with extra extensions to these elements to provide additional configuration in a declarative fashion without requiring the pollution of the business interface with jax-rs annotations ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
