Just a few notes:
On 18 October 2011 17:26, Troy A. Griffitts <[log in to unmask]>
wrot> Hey guys,
> 1) The clean distinction between Web API Services and OpenSocial Gadgets.
> They are not the same and are not tightly coupled. We have a suite of web
> services here for accessing our data which does not need OpenSocial in
> anyway. Our OpenSocial gadgets, of course, use them, but anyone (we grant
> permission to) can use them, as well.
Great, I am geared up to do the same.
Obviously I have a web service API already. I know you are not
'drinking the kool-aid' on the REST standard of small responses of
linked data, and I agree to some extent that the practicalities of
being asynchronous mean that bigger responses are sometimes better. I
am 'eating my own dog food' by creating the Birmingham Workspace using
just the API and no special access to the server. As I do this I
extend the responses to have the right amount of content (and no more,
so hopefully by the end of the process, the API will be close to what
you want in terms of the responses.
BTW, the responses are very small indeed, so they are easily
storage. You can just use the API URL as a key and the response (i.e.
a JSON object, which can be stored as a string) as the value. Then
just have a get method which checks if it exists before getting it. In
my frontend, I also store a timestamp to support expiry of cached
responses. When I am a bit further along, I will turn on all the
apache optimisations to make everything have expiry headers and so on
will try to cache and expire them automatically.
At some point I will also support the OpenSocial also. Exposing my
stuff as gadgets seems simple but being a "container" is a little more
difficult, but yesterday I played with Apache Shindig and that seems
the way to go, but is not entirely simple.
Someone has written a Shindig binging for Google App Engine
http://code.google.com/p/gae-opensocial/ If this works then it should
be possible to port this to Django since Google App Engine is based on
a subset of Django. If I get that to work then consuming OpenSocial
gadgets should be more-or-less automatic for Bham workspace.
> 3) The suggested way for OpenSocial Gadgets to authenticate to Web Services
> is with OAuth. OAuth facilities are provided to gadgets running in a
> portal. You can count on them being available to you when you write a
> gadget. So eventually we'll need to secure our services (especially the
> ones with a WRITE interface) with OAuth. Currently ours are open, as we
> have not deployed any live data just yet.
Good, I should (in theory) have OAuth support already in the
Birmingham Workspace API because it was bundled in the REST library I
am using, whether it is turned on or not is another matter.
Thanks for the examples, I will play with them later on.