I've been getting asked about this quite a bit, so I'll preemptively dump some info here.

var param = {};
param[opensocial.ContentRequestParameters.AUTHORIZATION] = opensocial.ContentRequestParameters.AuthorizationType.SIGNED; //Not implemented yet 

param[opensocial.ContentRequestParameters.METHOD] = opensocial.ContentRequestParameters.MethodType.GET; // POST for POST_DATA       param[opensocial.ContentRequestParameters.CONTENT_TYPE] = opensocial.ContentRequestParameters.ContentType.HTML; // only HTML is supported, but the content type is currently determined by the response - application/json is commonly used

// Certain headers are not modifiable, including those provided for you (Connection, Content-Length, Content-Type, Method)

param[opensocial.ContentRequestParameters.HEADERS] = {'header_name':  'header_value'}; //JSON style naming <string(header name),string(header value)> 

param[opensocial.ContentRequestParameters.POST_DATA] = "key1=value1&key2=value2";

opensocial.makeRequest(url, makeRequest_callback, param);

function makeRequest_callback(response, error) { if (!error) var content = response.responseText; }

As always, feel free to post if you have any problems.

Max 

We are getting errors from making requests that return gzip'ed responses....  EXAMPLE: 

http://local.yahooapis.com/MapsService/V1/geocode?appid=YahooDemo&street=701+First+Street&city=Sunnyvale&state=CA

any word when this will be supported?

Ooooo - keep breaking stuff =)

 I'll work w/ the proxy handler folks today to see if we can get that happier

Cheers,

Max 

are we being steered towards POST or is the following a bug? the call:

  opensocial.makeRequest("http://www.test.com/get_stuff?p1=10&p2=20&p3=30",  callback, {});

hits the following URL:

  http://www.test.com/get_stuff?p1=10?opensocial_viewer_id=xxxx&opensocial_owner_id=yyyy

this causes two problems: (1) the URL is broken and we have lost parameters, (2) even if the parameters were appended correctly to the URL with either ? or & depending on if i already had my own, automatically appending parms would break our ability to use HTTP caching (including local caching) to cache fragments across owners and viewers, which can be very useful for caching e.g. the entire profile contents slightly different ways purely per-owner, once for the owner, once for friends, and once for, say, non-app-users.

i'm going to switch to POST just to jigger this for now, but i would prefer to use GET and so would love to hear back on this issue. 

Do people feel this needs to be better reflected in the documentation?  What can we do to cover this better/

Thanks so much!

-- Ben Metcalfe 

 We're trying to get opensocial viewer/owner optional for querystring parameters, I'll post back once it's ready.   I'm also wrapping up some templating work to keep the MySpace extensions documentation up to date for everyone.

Cheers,

Max 

 Fuali-

We now support gzipped requests, so try it again!

Cheers,

Max 

The JS portion of SIGNED has already rolled out, the associated proxy pieces should be rolling (if they haven't already) very shortly.

 In the meantime, you can always append opensocial_authtype=SIGNED to your makeRequest url.

Cheers,

Max 

 So a big question from your exactly.

If I do a makeRequest... (type HTML.... whatever).. and the response does text/x-json or application/json.

Will I be able, in the future, to eval that response, or .toJson() it.. so that I can use it?>

THe case i'm thinking of... if I want to be able to defines some javascript functions .. that live on my server, that I can pass to an opensocial app for execution?

It is the ONLY way I can think, of having some aspects of the applications BEHAVIOR be changeable, without having to revisit myspace, and completely re-upload an app (and if there is a cache in the future etc, this would help to get around that).

the JSON would look like:"

{ setupUI: function() { function a() { etc}}}.

Very "jQuery" like.

I could then eval that json... var myObj = eval('(' + responseJson +')')... myObj.setupUI.

Will this work in the future (it works now)
 

Are you sure that the callback is defined the way described above? I'm seeing the proxy server failing to fetch my page quite frequently. when it FAILS the second parameter of the callback is the javascript undefined. when it WORKS the second parameter is a string containg some sort of proxy message or something.

That means that for me the 'error' parameter in the above code is logically 'true' when it succeeds and logically 'false' when it fails. Which would make that parameter ACTUALLY 'success'

incidentally, the failure rate is VERY high. about 50% per request for some trivial page of data off my quite reliable server (which works fine for facebook when facebook is working ok)

Actually, I take that back. the failure rate of makerequest seems pretty low today. It was just really bad last night. 

We had some issues with configuration to new servers we added to the cluster...thus the intermittent problems.  Things should be cleared up now.