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? >>>> >>>> >>> >>> >
