Ouch, yes, those samples are badly borked. It looks like they weren't updated when we revised the design.
On Tue, Aug 4, 2009 at 9:55 AM, Arne Roomann-Kurrik<[email protected]> wrote: > 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 >> >> > >> >> >> > >> >
