shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shreyas Desai (શ્રેયસ દેસાઇ)" <shre...@google.com>
Subject Re: Weird RESTful request in test suite: /appdata/OWNER_FRIENDS/@self/@app
Date Tue, 02 Sep 2008 19:09:19 GMT
0.7 spec says it does expect idSpec.
http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newFetchPersonAppDataRequest



On Tue, Sep 2, 2008 at 11:28 AM, Cassie <doll@google.com> wrote:
> This is happening because of this test:
>
> name: 'newFetchPersonAppDataRequest - OWNER_FRIENDS, \'*\')',
> id: 'APP007',
> ...
> req.add(req.newUpdatePersonAppDataRequest(
>     opensocial.DataRequest.Group.OWNER_FRIENDS, 'PDRT008_K1',
>     this.data.personalValue), 'k1Update');
>
>
> newUpdatePersonAppDataRequest accepts an id string (not an idspec) so the
> constant "OWNER_FRIENDS" is treated as a generic user id. The test should
> not be calling this method as OWNER_FRIENDS is not considered a valid id
> (unlike VIEWER and OWNER - which are valid ids).
>
> - Cassie
>
>
>
> On Tue, Sep 2, 2008 at 10:18 AM, Louis Ryan <lryan@google.com> wrote:
>>
>> This is definitely not a valid URL,
>>
>> /appdata/@owner/@friends/@app
>>
>> is the right URL to get "the appdata for the owners friends for the app
>> defined in the associated security token"
>>
>> On Thu, Aug 28, 2008 at 4:57 AM, Chris Chabot <chabotc@xs4all.nl> wrote:
>>
>> > While running the reference test suite I'm seeing a number of requests
>> > fail
>> > on URLs in the batch request like:
>> > /appdata/OWNER_FRIENDS/@self/@app
>> >
>> > Now you may color me silly, but i really would've expected something
>> > along
>> > the lines of:
>> > /appdata/@owner/@friends/@app
>> >
>> > I haven't had the time yet (I seem to have way to little of that these
>> > days) to diagnose if it's an invalid request from the test suite, or if
>> > it's
>> > the (legacy) rest-rpc code, but as far as i can tell, that shouldn't be
>> > able
>> > to happen :)
>> >
>> > Oh ps, it seems it's going wrong on the POST only, GET's work as
>> > intended
>> > (see batch blob below)
>> >
>> > Anyone have any ideas what could be causing that?
>> >
>> > Full batch request from the test suite (incase it helps to map it
>> > against
>> > the test #):
>> >
>> >
>> >
>> > {"k1Update":{"url":"/appdata/OWNER_FRIENDS/@self/@app?fields=PDRT008_K1","method":"POST","postData":
>> > {"PDRT008_K1":"personalValue
>> >
>> > 1219923727663"}},"k2Update":{"url":"/appdata/OWNER_FRIENDS/@self/@app?fields
>> > =PDRT008_K2","method":"POST","postData":{"PDRT008_K2":"personalValue
>> > 1219923727663"}},"per":{"url":"
>> > /appdata/@owner/@friends/@app?networkDistance=&","method":"GET"}}
>> >
>> >
>> >
>
>

Mime
View raw message