Hi,
Do we really want to allow arbitrary SCA services to be exposed to be
RESTful? REST (resource-oriented) is quite different from RPC
(operation-oriented). IMO, the component has to be designed following the
RESTful style where we might have a few different options:
* Use an interface that is compatible with the Collection pattern
* Use JAX-WS annotations to customize the mapping
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Thursday, March 25, 2010 1:55 AM
To: <[email protected]>
Subject: Re: JAX-RS as REST binding
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
