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>
Even if you could do
/people/@me/@self?
filter...@friends&filterOp=contains&filterValue=<someUserId>
it would *always* return an empty result set *unless* the social
networking
site allows for schizophrenic relationships and allowed you to
befriend
and/or unfriend your self :)
Really i think the query your looking for is /people/@me/@self/
<userId>,
which tells you if a person is a friend of '@me' or not (and returns a
single record), or
/people/@me/@friends?
filterBy=id&filterOp=contains&filterValue=<userId>,
which returns a collection with a 0 or 1 entries in it.
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).
On Fri, Feb 13, 2009 at 12:56 PM, Ben Smith <[email protected]>
wrote:
I'd personally prefer that as you'd get a more consistent response.
However, this would change the current response for @self requests
as it
would be wrapped in the output of a RestfulCollection object.
Currently a
response for an @self request returns <response><person></person></
response>
where as a request to @friends returns
<response><entry><person></person>[..]</entry></response>.
Interestingly.. if you read
http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml#rfc.section.3.1
it
agrees with you, that every request should be assumed to be a
collection,
even if it will only ever have one entry!
entry: an array of objects, one for each item matching the request,
as
defined in Section 11.1. For consistency of parsing, 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 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).
Therefore, I'll rescind my current patch and provide one that has
PersonHandler only use getPeople(). Plan?
Cheers,
Ben
On 13 Feb 2009, at 11:42, Ian Boston wrote:
Ben,
What is wrong with doing:
personService.getPeople(personSet, GroupId.Type.all,
collectionOptions,
fieldsSet, securityToken);
where personSet contains only the currentUser and the
collectionOptions is
as per the URL.
?
If that would give you what you want, there is no SPI change
required.
(tell me I have missed something if I have, no coffee yet :)
)
Ian
On 13 Feb 2009, at 11:32, Ben Smith wrote:
Please could someone have an opinion about
https://issues.apache.org/jira/browse/SHINDIG-904
There's a chance I need to provide a new patch as there have been
quite a
few changes since I originally provided it.
It is quite important for me to be able to provide the standard
parameters for 0.9:
http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml#standardQueryParameters
and
these need to be available to getPerson() to support the
following query:
/people/@me/@self?
filter...@friends&filterOp=contains&filterValue=<someUserId>
I realise that this change involves changing an SPI interface but
this is
the smallest, simplest change that was discussed a while ago,
which I then
submitted this patch for.
Cheers,
Ben Smith
