Apologies for addressing the emails in this thread out of order :)
I was on a similar track, thinking about implementing a REST
binding for Tuscany C++. I agree with you that the REST pattern is
about resources, so we need to go further than just sending XML
service requests over HTTP, and understand what it means to work
with resources in an SCA application.
I was thinking about starting with something very simple like this:
In an SCDL component reference:
<reference name="customers">
<interface.resource type="http://my.business.objects/#Customer"/>
</reference>
and later in a composite reference:
<reference name="customers">
<binding.rest/>
</reference>
QName "http://my.business.objects/#Customer"; specifies an XSD
complex type describing my Customer business object.
<binding.rest> loads my new REST binding extension that knows how
to send Customer resource requests over HTTP.
<interface.resource> indicates a fixed interface pattern with the
resource management / HTTP verbs.
In the client:
customers.get("http://my.customer.database.com/customers/1234";);
returns an instance of the Customer XSD complex type
customers.put("http://my.customer.database.com/customers/1234";,
customerDataObject) updates customer 1234 with a Customer instance.
customers.get("http://my.customer.database.com/customers/";) returns
a list of URIs to the customers.
On the server, the CustomerResource component implements the
Customer resource management verbs:
class CustomerResource {
DataObject get(string uri);
void post(string uri, DataObject customer);
void put(string uri, DataObject customer);
void delete(string uri);
list<string> list(string uris);
}
Yes I do like it, but I still have a fond attachment to the annotation
driven state-change -> method mapping :)
You have .put and .get in the client example, maybe the .post should be
something like
customers.post(uri, state-diff)
where state-diff is a state format dependent serialization.
Also, I was thinking that somehow our REST work should tie in with
the DAS work that we're doing in Tuscany.
+1 - I know little about the DAS stuff as yet, but the REST/CRUD/BREAD
approach has a strong affinity for data sources. IMHO this would be
a great first step!
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
