Guys am I on your spam lists and getting redirected to /dev/null or something? I feel a bit ignored
If you re-read the spec it says: " *if the request could possibly return multiple items*" .. then it has to be a collection /people/@me/@self is a **SINGLE** entry (the viewer, a single entity and not a collection of entities) and can **NEVER** return multiple entries, so that part in the spec about the collection does not apply. The same behavior can be found in activities, a collection is /activities/@me/@self (since it can return multiple activities), however /activities/@me/@self/<*ONE ID*> can only return *ONE ENTRY* hence it's not a collection. On Fri, Feb 13, 2009 at 1:18 PM, Ian Boston <[email protected]> wrote: > Yes that sounds like a good plan :) > > Thanks for explaining, I hadn't realized that the current response was non > spec compliant.... so you've fixed a bug as well which is even better. > > Thanks, > Ian > > > > On 13 Feb 2009, at 11:56, Ben Smith 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 >>>> >>>> >>>> >>> >> >
