Last Friday, the Salesforce Platform Developer Evangelism Team ran a (mostly) internal hackday, bringing together evangelists, support staff, product management, R&D engineers and a couple of special community guests for a day of exploratory hacking. Although the theme for the day was ‘Mobile’, this wasn’t a constraint, and I teamed up with sales support engineer Henry Liu to explore ql.io, a ‘declarative, data-retrieval and aggregation gateway for quickly consuming HTTP APIs’ created by eBay’s platform engineering group, in use (among other places) at Kinvey for integrating with third-party data sources. In this blog entry (the first in a three part series) I’ll describe how we got started, creating a simple wrapper for a Force.com REST API call.

This script from the examples page illustrates a typical ql.io use case, mashing up three different web services from two providers:

The inner select uses the eBay Finding API to search for items including the keyword ‘iPad’, while the outer select retrieves geographic coordinates for the items’ locations from the Google Geocoding API and item detail from the eBay Shopping API. ‘Tables’, defined elsewhere, hold the mappings to actual web service requests – the ql.io documentation does a good job of explaining how it all fits together. The query results are in JSON format:

Given that the table definitions add only a dozen or so more lines of script, it was clear that ql.io’s table abstraction would allow us to quickly integrate a bundle of different web services without writing a mountain of boilerplate code. We had a couple of goals in mind for the day – mashing up the Force.com REST API with Google Geocoding to get latitude and longitude for Account records, and filtering Chatter posts on keywords – but the first step was to figure out how to access the Force.com REST APIs from ql.io.

After a couple of false starts trying to configure ql.io with user credentials and have it login via OAuth Username-Password Flow, we realized that it’s best to think of ql.io as a filter, supplying it with an OAuth access token and instance url rather than configuring it to login itself. Simulating a client app, we obtained the necessary values via curl (parameters modified for this example!):

Now it was straightforward to create a script in ql.io/console that would retrieve a list of Accounts:

With the result:

This is a start, but, clearly, hardcoding access tokens into a web console isn’t a viable solution! It turns out that you can configure script routes in ql.io, wrapping select statements as web services, so, after a bit more prodding, poking and reading documentation, we created one file in the ql.io server’s tables directory:

And another in the routes directory:

We set those instance_url and authorization parameters via HTTP headers from a client, like this:

Et voilà:

So far, we haven’t done anything you can’t do by accessing the Force.com REST API directly, but next time, in part 2, we’ll see how, with a Formula Field and just a few lines more ql.io script, we can get the latitude and longitude for each Account from the Google Geocoding API, far quicker than if we implemented an equivalent REST Web Service in Apex, and without consuming any callouts.