Thanks, so the spec document is ambiguous in the way it presents the arguments list, and the samples are just plain incorrect. I'll make a note to propose a change on the spec list. ~Arne
On Mon, Aug 3, 2009 at 8:32 AM, Adam Winer <[email protected]> wrote: > 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 > >> > > >> > > >
