*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
