On Fri, Feb 13, 2009 at 1:09 PM, Chris Chabot <[email protected]> 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. > > 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. > doh i confused my self, that's supposed to be:*/people/@me/@friends/<userId> * > > > > 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 >>>> >>>> >>>> >>> >> >
