John Panzer (http://abstractioneer.org)
On Sun, Jul 13, 2008 at 12:45 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > Ok so i got the read (get) part of atom pretty much done, and the json part > has been baked for a while already, time to move on to the next bit. > > John: Please do ping me when you make any additions/changes to the document > so i can keep it up to spec.. it's been 2 months already that the spec's > been out and I'm getting a bit itchy to get something completed :) > > So we already have a Json based structure in place in Shindig for all write > actions we currently support (see below). However looking at the spec i see > mention of person's being created: > > POST /people/@me/@all HTTP/1.1 > Host: api.example.org > Content-Type: application/json > > ...representation of new Person elided... > > Now on i think pretty much all social network sites, creating people isn't > really something they would want to do through the REST API right? Not am i > assuming that we want people to be able to edit messages, people and > existing activities (that would be opening pandoras box) so assuming that's > correct, that bit of the documentation might be leading to the wrong > impression and might lead to people trying to PUT new accounts to myspace, > hi5, orkut, etc.. and then asking why it didn't work :) There's a spec diff proposal floating around on opensocial-and-gadgethat I think explains the intent here: "Clarification on RESTful People API, connections vs. contact records, and invitation workflow" (thread http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/2d542afdaf412c04). The example above was about how to make a link to a person, or start the workflow to make a link, not about how to create a new account in the SN. (Which actually would be an interesting operation to define, particularly for sites which have trusted partners who want to provision new accounts, but it's clearly a P2 spec feature.) > > > So for the atom style post/put/delete, what object representation are we > going to choose? Might it be worth spelling this out in detail in the REST > API spec too? I'm presuming we'll expect something like (for an activity): > > <entry xmlns="http://www.w3.org/2005/Atom";> > <streamTitle>My Stream</streamTitle> > <title>My activity</title> > <body>Activity body stuff</body> > <mediaItem> > <type>image</type> > <mimeType>image/jpg</mimeType> > <url>http://cdn.example.org/image.jpg</url> > </mediaItem> > <mediaItem> > <type>image</type> > <mimeType>image/jpg</mimeType> > <url>http://cdn.example.org/image.jpg</url> > </mediaItem> > </entry> > > I'd like to have this somewhat defined so we can keep the java and php > versions in sync and work the same out of the box, normally we have the > javascript features to verify both implementations but since that's missing > here some extra coordination might be good :) I'm a little confused... yes this is what we'd see for an activity (as an example). In other words, the thing you send is an OpenSocial Activity (in this case). AtomPub specifies what happens in response. What's missing? The object representation is exactly the data representation of the resources (Person, Activity, Appdata) that are documented in the earlier sections. You use these for PUT and POST, you get them on GET... this is all inherited from AtomPub. > > > Lastly, have we decided what to do with the json batching support yet? We > have a convenient well working mechanism in place now that i like a lot > because its quick, simple to use (for 3rd parties too) and ... well we > already have the code for it :) > > However the spec mentions a different mechanism: > POST /batch-proxy HTTP/1.1 > Host: api.example.org > Content-Type: multipart/mixed; boundary=batch-a73hdj3dy3mm347ddjjdf > > -batch-a73hdj3dy3mm347ddjjdf > ... etc ... > -batch-a73hdj3dy3mm347ddjjdf > ... etc ... > > For atom that makes a lot of sense but for json it feels like the current > method makes more sense. However if we decide to json batching in the same > way too, i'd rather have one code path to maintain then 2 types of json > batching :) > This one is still open. The advantage of JSON-only is that it works great for JSON-only clients :). The advantage of the multipart mechanism is that it works for all clients and all data types (including binary in the future). One critical question for this is how many libraries need to deal with the format (how critical is it that it be 'easy' as opposed to 'universal'). Anyway, this is a good spec discussion to take over to the opensocial-and-gadgets-spec list. > > thoughts? comments? > > -- Chris > >
