.

StatusLast UpdatedProposal IdSpec/Code ChangeSummaryThread link

.

This is only a structured local copy of the mailing list, filtered for RESTful API _spec_ issues only. It just summarizes everything that has taken place there. See http://groups.google.com/group/opensocial-and-gadgets-spec for more info. The latest spec doc is here:

.

Spec:http://docs.google.com/View?docid=dc43mmng_2g6k9qzfbThe live spec

.

Change History:https://docs.google.com/RevisionsTab?docid=dc43mmng_2g6k9qzfb&tab=revcomp&brev=dc43mmng_2g6k9qzfb:0&erev=dc43mmng_2g6k9qzfb:0&cancelRevision=&notifyURL=&inc=true&frev=dc43mmng_2g6k9qzfb:409&trev=dc43mmng_2g6k9qzfb:56

Diffs from original draft 2/1 to 3/6 draft

.

.

OpenSocial RESTful API Related Things...

.

.

In 3/2 spec4/28/2008RESTFUL-MSG(see thread)Send message user to user via RESTful APIhttp://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/6c9e80d205e158d2/f32e7f7a03a23824?lnk=gst&q=RESTful#f32e7f7a03a23824

.

In 3/2 spec4/28/2008RESTFUL-ENUMNeed to specify how to handle enum-type fields

.

Open4/28/2008RESTFUL-JSON-TYPESXML format needs to carry JSON type information

.

In 3/2 spec4/28/2008RESTFUL-JSON-QJSON uses double quotes for all strings, examples wrong

.

In 3/2 spec4/28/2008RESTFUL-META-NAMESNeed to separate meta-names from names; e.g., @self instead of self, @friends instead of friends

.

In 3/6 spc4/28/2008RESTFUL-URI-SCHEMENeed discoverable but simple URI schemes that are supportable across multiple container technologies

.

In 3/6 spec4/28/2008RESTFUL-JSON-COLLJSON collection format doesn't by default allow for collection metadata (e.g., # of entries, start index, etc.)

.

In 3/6 spec4/28/2008RESTFUL-BATCHUse application/http content type for batching (see James Snell's latest proposal).

.

In 3/6 spec but needs fleshing out4/28/2008RESTFUL-SECAdd section detailing interesting security use cases for context. Discussion: A lot of the security for this devolves to container policies, which we're
explicitly not specifying much of in OpenSocial. Perhaps the document could
list some reasonable policies, and point out dangers (in a security section)
to watch out for? For many situations, the policies are the same as for
sharing data with gadgets (given that gadgets can already communicate with
their home servers, from a security point of view the same policies should
apply to both I think, otherwise you have a security hole in one or the
other).

.

In 3/6 spec but needs fleshing out4/28/2008RESTFUL-SEC-POLICYDetails of security policies (belongs in spec?). See Paul Walker's discussion.http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/79d16e82dc6230e7/56c34a192a4f0e98?lnk=gst&q=RESTful#56c34a192a4f0e98

.

In 3/6 spec4/28/2008RESTFUL-FIELD-DESCNormative description of standard (required and optional) fields for e.g., Person. Can we just link to the JS API specs with a recipe for translation?

.

Open4/28/2008RESTFUL-FIELD-SUBSELECTShould fields= syntax be made required, and if so we need to document the exact syntax and semantics. Some containers cannot support returning arbitrary sets of fields but can support returning "minimal cover" of fields.

.

Open4/28/2008RESTFUL-PARTIAL-UPDATESShould we make partial updates required for containers? This is a change to the spec. Could be required only to use to implement the JS API, or required across the board.