Fair enough. XSD says it's cool. This should probably be reflected in
the spec.. but I'm not going to loose any more sleep over it ;)
On 13 Feb 2009, at 14:59, Ian Boston wrote:
The XML Schema was aligned with portable contacts, and a version of
that xsd is used to validate the responses.
So the response you see from the sample container *should* be
correct wrt the xsd.
Since that work was done, the xsd has moved on a small amount, but I
think the response is correct, no entry. Inspecting the xsd should
be validate that. see section 2.2 of http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol
or
http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api/src/test/resources/org/apache/shindig/social/opensocial/util/opensocial.xsd
I think this says <person> can be a top level element.
Ian
On 13 Feb 2009, at 14:35, Ben Smith wrote:
Cool.
FYI. Running Jetty from trunk and going to /people/canonical/@self?
format=xml gives the following response:
<response><person>
<id>canonical</id>
...
</person></response>
I'm guessing that is a bug as there is no <entry> wrapped around
the person object?
On 13 Feb 2009, at 13:47, Ian Boston wrote:
Sounds good,
So thats a call to getPeople(....)
put the Future response inside another Future response that
unwrapps the RC<Person> into a Person... if there is one,
otherwise respond with a 404.
and yes a single entry not a collection.
Ian
On 13 Feb 2009, at 13:41, Chris Chabot wrote:
Ah right, yeah that's indeed from
http://wiki.opensocial.org/index.php?title=Implementing_IS_FRIENDS_WITH
In which case I guess we should respond to that one filter option
in the
getPerson(), however it should still be a single entry and not a
collection
:)
On Fri, Feb 13, 2009 at 2:30 PM, Ian Boston <[email protected]> wrote:
I agree filtering on a single entity is silly:
But under the table of section 7.9 of the spec at
http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
"
/people/@me/@self?
filter...@friends&filterOp=contains&filterValue=<someUserId>
This will return nothing if the other ID is not a friend, the
current user
if the two are friends. filterValue may take a specific person
identifier of
@owner or @viewer.
"
Which implies that filtering on the *single* @me/@self entity is
the way to
find if the current user is friends with the specified user.
Back in the early thread, (about a week ago) I think I said the
spec looked
odd.
This is where the original URL that started this thread comes
from.
---------------------------
So a question for you, Chris,
should /people/@me/@self respond to filtering?
Ian
On 13 Feb 2009, at 12:58, Chris Chabot wrote:
There's really no need to assume anything, /people/@me/@self is
a single
entity and can never be more then one result.
Hence filtering is a bit silly, what exactly would you want to
filter on,
what would be the use-case for wanting to know a viewer *only if
<condition>* ?
The only situation in which /people/@me/@self returns an error
is when
your
using 2 legged OAuth (or anonymous read access is allowed), in
which case
the securityToken's getViewer() will throw an exception since
@me can't be
resolve to an ID in those situations.
In every other situation, getViewer() returns an id, which is
used to
resolve @me/@self to a single user record, which is not really
filterable,
since filtering only makes sense on collections, right?
On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <[email protected]>
wrote:
Can I unwind this a little please.
The original patch for 904 was to introduce a change the SPI for
getPerson
with filtering.
I argued that getPeople already provides the filtering so
there was no
need
for a SPI change.
Ben pointed out that the REST response would then be a
collection which
exposed a tension in the spec.
Did I get that right?
Lets assume for a moment that the output of the current
servlet *is*
correct (ie not a collection)
having called getPeople check the response and emit a 404 if
there are 0
entries and the only entry if there is 1 (there should not be
more than 1
as
a result of the filter). Obviously the Future needs to be
wrapped to
evaluate this when its needed and not before.
Does that make sense?
I think if they current servlet is not correct then that needs
sorting
out
separately, but I see emails on this thread stacking up faster
than I can
type or think or answer the phone.
Ian
On 13 Feb 2009, at 12:36, Chris Chabot wrote:
On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <[email protected]
>
wrote:
On 13 Feb 2009, at 12:09, Chris Chabot wrote:
'@self' is not a collection by any definition of the word,
it's a
single
object, hence the lack of the collection (and the lack of
filtering,
there
is only one 'self' and that's the viewer :)
The same goes for activities, a query on /activities/@me/
@self returns
a
collection of activities (since it can contain 0, 1 or many
results),
however /activities/@me/@self/<activityId> can only return
0 or 1
results,
so it returns an activity record and not a RestfulCollection.
But that's not what the spec says should happen: If the
request is
specifically for a single contact (e.g. because the request
contains
Additional Path Information like /@me/@all/{id} or /@me/
@self), then
entry
MUST be an object containing the single item returned (i.e.
"entry": [
{
/*
first item */ } ] and "entry": { /* only item */ }
respectively).
Unless I'm reading it wrong, /@me/@self should still return
<response><entry><person></person></entry></response>
There are 2 parts to the definition:
1) if the request could possibly return multiple items (as is
normally
the
case), this value MUST always be an array of results, even if
there
happens
to be 0 or 1 matching results
if something could return multiple entries it has to be a
collection,
however /@me/@self is a single entry, so this doesn't apply
here
2) If the request is specifically for a single contact (e.g.
because the
request contains Additional Path Information like /@me/@all/
{id} or
/@me/@self), then entry MUST be an object containing the
single item
returned
So if the query is for /@me/@self it *MUST be a single entry.*
I think your either confused and consfusing /@me/@self with /
@me/@all
(which
is an PortableContacts way of saying /@me/@friends), or your
a believer
in
possessions and believe that our definition of a person being
a singular
entity is wrong and the spec should be changed to allow for
multiple
spirits
and/or demons in one physical body. (And i truly hope that is
not what
your
suggesting :)
I agree that filter...@friends&filterValue=<userId> is
confusing, but
filterBy=id&filterValue=<userId> would surely remove all
people that do
not
have <userId> as their userId! I guess you really want a
filterBy AND
filterOn (or something), or explicitly name filterValue to
filterUserIdValue
(or something).
Filtering on /@me/@self is confusing, since it's only one
record, what
would
you want to filter on?
