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 :)
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 :)
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 :)
thoughts? comments?
-- Chris
