Mashup Standards Part 1: JSON-P

In a recent project, I had a client who wanted to resurface Oracle UCM content on another web page. The normal process would be to use some back-end technology -- like SOAP, CIS, or RIDC -- to make the connection. But, as a lark, I thought it would be more fun to do this purely as a mashup. I would need to tweak UCM to be more "mashup-friendly" -- I'll be sharing the code (eventually) -- but first I needed to do some research on the best mashup "standard" out there.

UCM supports JSON, but that's not enough for a true mashup. The problem is that even though UCM can send back JSON encoded responses, you cannot access this data from a different web page. This is because of the "Same-Origin Policy" in AJAX. Basically, you can make an AJAX call back to the originating server, but you cannot make it to a different server. This is quite annoying, because then you can't "mash-up" UCM content onto another web page using just JavaScript. The best mashup APIs -- like Google Maps -- can't use AJAX because of this limitation.

Many developers consider this 'security' feature quite odd, because it's totally okie-kosher to include JavaScript from other people's web sites... so why not AJAX? Knowing full well that this was kind of stupid, some developers came up with a 'convention' for fixing it: "padded JSON," or JSON-P. This means 'padding' a standard JSON response with a callback, and then calling that callback function with the response. For example, if you called the PING_SERVER service with JSON enabled, with a URL like so:

You would get back the following JavaScript response:

{ LocalData: { StatusMessage: "You are logged in as sysadmin", StatusCode: 1} }

You would then use the standard AJAX XmlHttpResponse object, parse this JSON data, then do something with the message. My jQuery Plugin for UCM does exactly this... but of course has the limitation that it will only work on HTML pages served up by UCM. You can use fancy proxies to bypass this limitation, but it's a pain.

Instead, if UCM supported 'padded JSON', the process would be different. The URL would look something like this:

And the JavaScript would instead look like this:

processData({ LocalData: { StatusMessage: "You are logged in as sysadmin", StatusCode: 1} });

In this case, the callback=processData parameter triggers the server to 'wrap' the JSON response into a call to the function processData. Then, instead of using the XmlHttpResponse object, you'd use good old-fashioned remote scripting. Like so:

function pingServer() { var url = "" var scriptNode = document.createElement("script"); scriptNode.src = url; document.body.appendChild(scriptNode); } function processData(ucmResponse) { var msg = ucmResponse.LocalData.StatusMessage; alert(msg); }

Notice how we define a function on the page called 'processData.' When the UCM response returns, it will call that function with our response data. The beauty here is that you can put this JavaScript on any web page in your enterprise, and connect directly with UCM with nothing but JavaScript. Pretty nifty, eh?

Now... JSONP is a good idea, but it's about 5 years old... A lot of newer browsers support a slightly different standard: Cross-Origin Resource Sharing. It's an actual standard, unlike JSON-P which is more of a convention... the purpose is to safely allow some site to violate the silly "Same-Origin Policy". I'll be covering CORS in part 2 of this post, including the security enhancement. But, in part 3 I'll explain why I still prefer JSON-P, provided you add some extra security.

So.. Where the JSONP UCM

So.. Where the JSONP UCM update integration component :)
&callback hasn't been integrated by oracle - although I did submit it as a recommendation..

Looks like they may be taking it a step further allowing you to customise the json template ;)
John Sim.


I'll be releasing it soon... when I get to part 3 of my blog post. ;-)


The theme of your blog is really fresh, I'm positive that the people who will find your blogs will benefit your content and advice.

Recent comments