More ideas and questions below.
Oisin Hurley wrote:
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 :)
What do you think about the following approach:
a) If you put no annotations in your code then you have to stick to the
fixed pattern with fixed method names, and you write the side SCDL file
that turns your code into a component and publishes the REST endpoint.
b) If you want more flexibility to map state changes to nicer method
names then you use annotations as your were proposing earlier in this
thread. The annotations also allow you to completely avoid writing SCDL
and specify the details of the binding like the base URI for the
resources...
Thoughts?
You have .put and .get in the client example, maybe the .post should be
something like
customers.post(uri, state-diff)
Ah! interesting, I never thought about that before, looks like there
could be a pretty good fit with SDO with the following:
customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ...
This would be an interesting usage of SDO change summaries IMO,
obviously just as an option as you should be able to format your state
diff in any format you want as long as it's understood by your application.
What do you think?
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]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
