On Sun, Aug 2, 2009 at 3:03 AM, Arne Roomann-Kurrik<[email protected]> wrote:
> I've been working with this code in PHP shindig this weekend and noticed an
> inconsistency - from
> http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Specification.html#osapi.http
> :
>
> The method signatures are listed in the form:
>
> osapi.http.get(params)
>
> which has a single parameter object as its argument. The parameters list,
> however, claims both "url" and "params" as possible arguments, and the
> samples show code in this form:
>
> osapi.http.post('http://example.com', params).execute(function(result) {
> if (!result.error) {
> alert('Request to update user preferences was successful');
> }
> });
This is wrong. The input must be a single JSON argument, as with all
other osapi methods.
> osapi.http.get(url, params) is a bit more in line with makeRequest and seems
> to be the intent of how this portion of how the spec was written.
We don't want to be in line with makeRequest(), or anything else from
0.8 - osapi is intended to be internally consistent.
> However,
> the new JavaScript osapi autoconfigure code only forwards one argument, so
> calling:
>
> var params = {
> 'format': 'json',
> 'authz': 'signed'
> };
> osapi.http.get('http://www.opensocial.org', params).execute(function(data)
> {});
>
> sends the following request body to the server:
>
> [{"method":"http.get","id":"http.get","params":"http://www.opensocial.org"}]
>
> What's the correct functionality here? How many arguments do osapi.http
> methods require? Does the osapi.http autoconfigure code need to be changed?
The correct call is:
osapi.http.get({
url: 'http://www.opensocial.org',
authz: 'signed',
format: 'json'
}).execute(.....);
>
> ~Arne
>
>
> On Tue, Jul 28, 2009 at 10:02 AM, Adam Winer <[email protected]> wrote:
>
>> Endpoints are either dynamically retrieved, or statically configured,
>> but in either case you don't need any direct javascript/features code
>> for any of the endpoints. (An exception is the convenience methods in
>> osapi.people).
>>
>> The orkut and iGoogle issues look like a config issue on Google's end.
>> Partuza, haven't looked, can't say.
>>
>> On Tue, Jul 28, 2009 at 9:40 AM, Arne Roomann-Kurrik<[email protected]>
>> wrote:
>> > Is osapi.http one of the automatically configured parts of osapi? I'm
>> > trying to figure out what the accepted parameters are to clarify the spec
>> a
>> > bit, but I don't see anything in
>> >
>> http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/src/main/javascript/features/(or<http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/src/main/javascript/features/%28or>
>> > by grepping through a checked out version of shindig).
>> >
>> > Additionally, I thought this method was live on a couple containers, but
>> > trying to use it on orkut, iGoogle, or Partuza results in "osapi.http is
>> > undefined" errors, even though it looks like osapi.people, osapi.appdata,
>> > etc are available.
>> >
>> > If there's source, can someone point me in the right direction? Does
>> anyone
>> > have any ideas of why I might not be seeing osapi.http on container
>> > sandboxes?
>> >
>> > ~Arne
>> >
>>
>
