I don't know about java, but with php-shindig /social/rest/people/@me/@self
returns:
{"entry":{"isOwner":true,"isViewer":true,"displayName":"Chris
Chabot","id":"1","thumbnailUrl":"http:\/\/www.partuza.nl
\/images\/people\/1.96x96.jpg","profileUrl":"http:\/\/www.partuza.nl
\/profile\/1"}}
which is exactly as you described it. (steal a security token from an app on
www.partuza.nl and try it your self on
http://modules.partuza.nl/social/rest/people/@me/@self?st=<securityToken>)
including totalResults in a single entry seems a bit silly, since this can
always be hard coded to '1', or have a '404' (not_found) error and no
entries, hence only wastes bytes and serves to confuse. I guess that could
be made a bit more clear in the spec text though
On Fri, Feb 13, 2009 at 1:35 PM, Ben Smith <[email protected]> wrote:
>
> On 13 Feb 2009, at 12:25, Chris Chabot wrote:
>
> Guys am I on your spam lists and getting redirected to /dev/null or
>> something? I feel a bit ignored
>>
>
> Sorry.. I'm just a slow typer ;)
>
> 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.
>>
>
> But then the next section says that /@me/@self requests should still be
> wrapped by the 'entry' element. The top of 2.1 says that elements like
> 'totalResults' must be returned too (and doesn't say anything about
> /@me/@self being different).
>
>
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
