My only objection to this proposal so far is that it punts everything over to OAuth on the security and authentication front, and OAuth doesn't answer any of the interesting security questions. For example:
- who (in real life) will the caller of the APIs be? Are these gadget home servers? Consumers? Somebody else? - what permissions are the callers of the APIs intended to have? - how will the container know to trust the caller of the APIs? - how will keys be distributed? - how will keys be changed? Good answers to those questions will probably be necessary in order for these APIs to interoperate across containers. It might be worth holding up the implementation until we're confident we understand how security is going to work. Cheers, Brian On Sun, Mar 30, 2008 at 12:32 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > +1 Very interested in getting this moving. > > > > On Tue, Mar 25, 2008 at 2:07 PM, John Panzer <[EMAIL PROTECTED]> wrote: > > Summary: > > > > Do we have a consensus on the broad outlines of the OpenSocial RESTful API > proposal? Please reply with +1 if you agree with moving forward with the > current spec (https://docs.google.com/Doc?docid=dc43mmng_2g6k9qzfb&hl=en) > while filling in the details as we build up a reference implementation. I > hope we can declare consensus by this Friday at the latest. > > > > More details: > > > > Most people seem to be generally okay with the proposal. While details > remain to be hammered out, a lot of these are best addressed in conjunction > with creating a reference implementation. David Primmer volunteered on > shindig-dev to help create a Java reference implementation as part of the > Shindig project, and others have expressed an interest as well. I'd like to > give them a green light to go ahead on this, and to do that I'd like to take > a straw poll of the people on this group to see if we have a consensus on > the basic ideas in this proposal. What this means is that you're okay with > the overall framework, think it's the right time to start a reference > implementation, and the only things remaining to be done are details or > optional parts of the spec. > > > > My personal list of current spec issues, from email threads: > > > > 1 [EMAIL PROTECTED] Need enum-type field in person example > Can we get a good example? > > 2 [EMAIL PROTECTED] Add optional <summary> element in person to > provide for feed reader viewing Added a note with a placeholder -- how > should a client request such an element? > > 3 [EMAIL PROTECTED] Does application/json content with no type > imply 'text' as in Atom? Yes. > > 4 [EMAIL PROTECTED] Should escaping of HTML content be part of > the JSON format spec (matching Atom) or left to the client (more JSON-y)? > Believe this should be escaped as is -- based on security discussion on > shindig-dev. > > 5 [EMAIL PROTECTED] How does AppData JSON represent substucture > It's turtles all the way down. > > 6 [EMAIL PROTECTED] XML in content needs to carry JSON type > information, JSON true/false/null may need special handling Query: Can > lack of a type attribute indicate string type? > > 7 [EMAIL PROTECTED] JSON spec requires double quotes for all strings, > spec should adhere to that Agreed, looking for a good find & replace > utility. > > 8 [EMAIL PROTECTED] Need a linking structure that doesn't muddy REST > semantics for updates -- collection of data of friends of a user is > immutable, so we need to have implicit or explicit links to an editable > resource. Agreed, should this be part of discovery? > > 9 [EMAIL PROTECTED] Need to work on url scheme to make resource > identification more deterministic; e.g., we can't use 'self' as a group name > in /people/{uid}/self vs. /people/{uid}/{groupid} Suggestion: @self? > > 10 [EMAIL PROTECTED] Use of PUT/DELETE are a non-trivial barrier to > adoption for many developers Believe this was addressed in email > > 11 [EMAIL PROTECTED] Need to at least be able to specify a > per-container URL prefix (container can pick a "base URL"). Agreed, added > a placeholder > > 12 [EMAIL PROTECTED] Can we provide batching in a JSON-list manner as > well? E.g., via a single JSON document, specify multiple operations in a > list. If needed, this could be added as an alternative batch format -- > the logic stays the same. Would like to get more input on cost/benefit > ratio of requiring this. > > 13 [EMAIL PROTECTED] Advise against using URL template rules for > discovering collections (see > http://www.xml.com/pub/a/2005/04/06/restful.html). Forces all requests to > go through single domain name. Agreed with the critique, but would like > to have more input on the cost/benefit ratio of adding more complicated > discovery > > > > I also welcome co-editors and/or a better way to track and annotate > issues. We have the existing site, > http://code.google.com/p/opensocial-resources/issues/list, which could be > used to track spec issues, though it's not clear to me exactly how they > could be easily separated from other issues (there are labels, but those are > applied by project owners at triage time, not at input time). Looking for > input here. > > > > Thanks, > > John > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "OpenSocial and Gadgets Specification Discussion" group. > To post to this group, send email to > [EMAIL PROTECTED] > To unsubscribe from this group, send email to > [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en > -~----------~----~----~----~------~----~------~--~--- > >
