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 :)
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 ;)
Are we close enough to condense a summary on the topic of
REST and SCA? This would be good white paper material BTW.
cheers
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
