Oisin Hurley wrote:
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?
These sound like good approaches to me - the one thing
that I'm scratching my head about a bit is the create-resource
and delete-resource support. The read-resource and update-resource
ops are fine, because we have a resource (i.e. the thing that
has just been coded). What's implicit here, though, is that
there is always a fixed set of resources - the ones that you
have just 'deployed'. So the create/delete ops can never be
used because things are just set up that way.
BTW, this is probably ok and it does match nicely with the
accepted admin practice of disabling PUT and DEL in real
webservers (as observed previously in this thread).
I would be happy enough to leave off the create/delete support
for the immediate future :)
Oisin,
I am not sure I understand the issue with create/delete (except if PUT
and DEL are disabled). Posting/putting to a URL that doesn't exist yet
to create that resource can be troubling. Is that the issue? Are you
looking for some kind of factory service pattern to create resources?
Or am I completely mis-understanding the issue you're describing here? :)
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?
This sounds like a nifty fit for sure. But now I have to
go and read that SDO spec in more detail, because I know
too little about it :)
I like the general approach of going down the diff route
because if you do it right then you can undo/redo changes
to the data, which is neat feature, provided you are willing
to store all of the diffs in a timeline.
I'll go off and read that spec again. I just love reading
specs ;)
I don't think that we would mandate the use of SDO change summaries to
implement this, support for diffs cannot be SDO specific (IMO the
application developer decides what a diff looks like and what he does
with it) but we would describe how application code could use SDO to
simply implement that approach. Does that make sense?
Are we close enough to condense a summary on the topic of
REST and SCA? This would be good white paper material BTW.
Yes I think it would be great if we could condense this and post it to
our Wiki maybe.
cheers
--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]
