So the Google Buzz API has been available for a month and I've added all kinds of value to this example code. Below is a link to all those folks I follow (who have supplied an image):

It's trivial and yields a social graph in four lines of code essentially. Nice! The only thing we needed to consider was the use of response.data.entry instead of response.data.item which became obvious by looking at this JSON showing who I follow on Buzz.

Because most of our data-related time is in XML land immediately we think XSD and find there exists something similar for JSON. JSON Schema! The Address Schema, for example, looks reasonable but we wonder how necessary all those double quotes might be. They seem to be redundant tokens that only reduce readability. Otherwise it's friendly enough.

The following StackOverflow post is interesting not so much because of the text but how it's rendered.

We begin with a <div> tag which contains an expected id attribute format and using a jQuery regular expression we're able to match all div elements with an "id" attribute beginning "RSSContent".

<div id="Container">
    <div id="RSSBlock">
        <div id="RSSContent200909222115" 
            runat="server" 
            title="http://stackoverflow.com/feeds/question/477962"  />
    </div>
</div>

The "title" attribute for each element matched is used in an HTTP post of content-type application/json to a web service which acts as a proxy to overcome cross-scripting JavaScript constraints. This returns the post above which I found useful recently.

It's not an elegant solution. I've hacked the div element, using the "title" attribute to hold the URL and the directory structure isn't great either. The web service creates a user control which appears to work only in the root directory and the web application project requires a reference to an identical control in another project. The things we do for code compilation!

The end result is that rather than cut & paste, which would have been far easier we're using using an external resource to supply text so that if the RSS feed item was to change, for example, then we'd still display the most current version.

An XLink implementation, this is not. It's just an example of how I thought the web might work sometime soon after 2001... What we're missing here, conceptually at least, is meta to describe the relationship between this post and the one referenced. Well, in this case the meta is only human-readable and quite incomplete.

So we had the option of writing some code in order to determine browser responsiveness to see whether the code in the last post - AJAX and the URL short(ening) - was in fact asynchronous... or use jQuery which we know is most definitely AJAX. Really, we're not in the mood for poking under the hood.

There was a wee bit of pain in the why now isn't ths working stakes, some edits later and it did. Mysteriously. So I didn't touch it anymore. A case of Programming by Coincidence?

<script src="Scripts/jquery-1.2.6.js" type="text/javascript"></script>
    <script type="text/javascript">
        $(function() {
            var getBitlyUrl = function() {
                
                // set up default options
                var defaults = {
                    version: '2.0.1',
                    login: 'bitlyapidemo',
                    apiKey: 'R_0da49e0a9118ff35f52f629d2d71bf07',
                    history: '1',
                    longUrl: $('#rawUrl').val()
                };

                // Build the URL to query
                var daurl = "http://api.bit.ly/shorten?"
                    + "version=" + defaults.version
                    + "&longUrl=" + defaults.longUrl
                    + "&login=" + defaults.login
                    + "&apiKey=" + defaults.apiKey
                    + "&history=" + defaults.history
                    + "&format=json&callback=?";

                $.getJSON(daurl, function(data) {
                    $('#bladder').empty();
                    $('#bitlyUrl').val(data.results[defaults.longUrl].shortUrl);
                });
            }

            $('#getUrl').bind('click', getBitlyUrl);
        })
        (jQuery);
    </script>

The body is the same as in the previous post. It's that easy. Great library.

Notes:
One of the leetlest problems we had was with receiving a 'permission denied' error when omitting "&format=json&callback=?" from the default URL. Solution and Nabble discovery all at the same time!

A popular choice for shorterning URLs on Twitter is Bit.ly. It's just so nice and tidy with great analytics. For example, not long after shortening http://cnn.com/ we discovered that there have already been 2,659 clicks to that URL via Bit.ly.

I am using the C# API from @kersney by the way and found out that Bit.ly does do the sensible thing and return the same shortened URL each time you supply an unadulterated URL. What I've not yet done is built chains of shortened URLs that lead to each... seemingly endless possibilities! What the C# API code is missing is &history=1 querystring parameter to have the shortened URL added to the list displayed in Bit.ly History.

Some Default.aspx code to give this a go:

<body>
    <form id="form1" runat="server">
    <div style="width: 100%;">
        Original URL:
        <asp:TextBox ID="TextBox1" runat="server" Width="100%"></asp:TextBox>
        <div style="text-align: right; width: 100%">
            <asp:Button ID="Button1" runat="server" Text="Shorten" onclick="Button1_Click" />
        </div>        
    </div>
    <asp:TextBox ID="TextBox2" runat="server"></asp:TextBox>
    </form>
</body>

And some codebehind:

protected void Button1_Click(object sender, EventArgs e)
{
    TextBox2.Text = API.Bit("bitlyapidemo", 
                            "R_0da49e0a9118ff35f52f629d2d71bf07", 
                            TextBox1.Text, 
                            "Shorten");
}

Now we pretend that bit.ly takes ages to return a shortened URL so we use javascript instead.

<script src="http://bit.ly/javascript-api.js
             ?version=latest
             &login=bitlyapidemo
             &apiKey=R_0da49e0a9118ff35f52f629d2d71bf07" 
        type="text/javascript">
</script>

<script type="text/javascript">

    BitlyClient.addPageLoadEvent(function() 
    {
        BitlyCB.shortenResponse = function(data) 
        {
            var s = '';

            var first_result;
            // Results are keyed by longUrl, so we need to grab the first one.
            for (var r in data.results) {
                first_result = data.results[r]; break;
            }
            for (var key in first_result) {
                s += key + ":" + first_result[key].toString() + "\n";
            }

            document.getElementById("bitlyUrl").value = first_result['shortUrl'];
        }
    });

    function getBitlyUrl() 
    {
        BitlyClient.shorten(document.getElementById("rawUrl").value, 'BitlyCB.shortenResponse');
    }
</script>

No prizes for guessing the elements in the document.

<body>
    <form id="formeula1" runat="server">
    <div style="width: 100%;">
        <br />Original URL:
        <br /><input type="text" id="rawUrl" size="100" value="http://wimiro.com" />
        <input value="Shorten" type="button" onclick="getBitlyUrl()"/>
        <br />
        <br />Bit.ly URL:
        <br /><input type="text" id="bitlyUrl" size="20" />
    </div>
    </form>
</body>

So, there are no postbacks anymore but does this make it AJAX? Honestly, I have no idea. I see mention of callback_method_name in the bit.ly javascript api so my guess is that, yes, this is asynchronous. But shall we bother to test this or do we try and involve jQuery?