Raible Designs

GWT OAuth and LinkedIn APIs

When I worked at LinkedIn last year, I received a lot of inquiries from friends and developers about LinkedIn's APIs. After a while, I started sending the following canned response:

For API access to build LinkedIn features into your application, fill out the following form:

   http://www.linkedin.com/static?key=developers_apis

For requests to build an application, go to:

   http://www.linkedin.com/static?key=developers_opensocial

I talked with the API team and they did say they look at every request that's sent via these forms. They don't respond to all of them b/c they know that many people would be angry if they told them "no", so they'd rather not have that headache.

Yesterday, I was pumped to see that they've finally decided to open up their API to Developers.

Starting today, developers worldwide can integrate LinkedIn into their business applications and Web sites. Developer.linkedin.com is now live and open for business.

First of all, congratulations to the API team on finally making this happen! I know it's no small feat. Secondly, it's great to see them using Jive SBS for their API documentation and developer community. My current client uses this to facilitate development and I love how it integrates a wiki, JIRA, FishEye, Crucible and Bamboo into one central jumping off point.

I've always been a fan of LinkedIn, ever since I joined way back in May 2003. However, I've longed for a way to access my data. LinkedIn Widgets are nice, but there's something to be said for the full power of an API. Last night, I sat down for a couple hours and enhanced my Implementing OAuth with GWT example to support LinkedIn's API.

I'm happy to report my experiment was a success and you can download GWT OAuth 1.2 or view it online. For now, I'm simply authenticating with OAuth and accessing the Profile API.

In the process, I learned a couple things:

• LinkedIn's OAuth implementation returns an oauth_verifier parameter after authenticating, whereas Google and Twitter do not. This parameter needs to be included when calling the Access token path.
• The Profile API example I implemented gets the current user's profile with http://api.linkedin.com/v1/people/~. This returns a "light" version of your profile. To get a more detailed version, you need to use Field Selectors. For example: http://api.linkedin.com/v1/people/~:(id,first-name,last-name,picture-url,headline,summary,positions,educations)
• LinkedIn's API only supports passing OAuth parameters in a header, rather than query parameters. To make this work, I modified my ProxyServlet to convert query parameters to an "Authorization" header at the end of the setProxyRequestHeaders() method.

// For LinkedIn's OAuth API, convert request parameters to an AuthorizationHeader
if (httpServletRequest.getRequestURL().toString().contains("linkedin-api")) {
    String[] parameters = httpServletRequest.getQueryString().split("&");
    StringBuilder sb = new StringBuilder("OAuth realm=\"http://api.linkedin.com/\",");
    for (int i = 0; i < parameters.length; i++) {
        sb.append(parameters[i]);
        if (i < parameters.length - 1) {
            sb.append(",");
        }
    }

    Header authorization = new Header("Authorization", sb.toString());
    httpMethodProxyRequest.setRequestHeader(authorization);
}

You might recall that my previous example had issues authenticating with Google, but worked well with Twitter. LinkedIn's authentication seems to work flawlessly. This leads me to believe that Twitter and LinkedIn have a much more mature OAuth implementation than Google.

Related OAuth News: Apache Roller 5 will be shipping with OAuth support. See Dave Johnson's What's New in Roller 5 presentation for more information.

Update December 6, 2009: I modified the gwt-oauth project to use GWT 1.7.1 and changed to the Maven GWT Plugin from Codehaus. Download GWT OAuth 1.3 or view it online.

User Interface Schema Definitions

On my current project, we're developing a "designer" tool that allows users to build forms in their browser. These forms are displayed in various channels (e.g. web, mobile, sms) to capture data and make decisions based on user input.

When I joined the project, it was in a proof-of-concept phase and the form definitions created where serialized as XML (using JAXB) with element names that seemed logical. Now that we're moving the PoC to production mode, we're thinking it might be better to change our form definitions to leverage something that's more "industry standard". If nothing else, it'll help with marketing. ;-)

This week, I was tasked with doing research on "existing user interface schema definitions". I'm writing this post to see if there's any major specifications I'm missing. I plan on providing my recommendation to my team on Monday. Here's what I've found so far:

• User Interface Markup Language (UIML): At 120 pages, the 4.0 spec seems very detailed. I'm not sure we'd use all of it, but it's interesting how the spec allows you to describe the initial tree structure (<structure>) and to dynamically modify its structure (<restructure>). It also has the notion of templates, which mirrors a similar concept we have in our application. Furthermore, it has VoiceXML support, which could be useful if we use call centers as a channel.
• USer Interface eXtensible Markup Language (UsiXML): I admit that I haven't read much of this specification -- mostly because the UIML spec seemed to cover most of what we needed (especially since we're most interested in describing forms). As far as a I can tell, the major difference between UsiXML is its being submitted to the W3C for standardization (according to Wikipedia), while UIML is being standardized by OASIS. Beyond that, I find it strange that UIML's spec is 120 pages and UsiXML is 121. Neither project seems to have any activity this year.
• Numerous others: including AAIML, AUIML, XIML, XUL, XAML and XForms. XForms seems like it may be the most logical if we're only interested in form layout and describing elements within them.

If all we're interested in is an XSD to define our forms, the most appealing specs have them: UIML, UsiXML and XForms. If activity is any sort of motivator for adoption, it's interesting to note that XForms 1.1 was submitted as a W3C recommendation a couple weeks ago (October 20, 2009).

If you've developed some sort of "form designer" tool that renders to multiple channels, I'd love to hear about your experience. Did you use some sort of industry standard to define your form elements, layout, etc. or did you come up with your own?