'@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. 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. 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 >>> >>> >>> >> >
