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