Blog

We have a client whose current web development platform is ExpressionEngine 2. We built a Salesforce integration onto that platform because much of their business processes and client relations take place inside their Salesforce instance. They provide an extensive directory of products in the commercial and home construction vertical. These are managed through Salesforce. We pull the data back over into ExpressionEngine, process it through several layers of business rule filters, then render it for the various audiences our client reaches.

Our client realized that one segment of their audience could benefit greatly from having access, programmatically, to an API of the product directory. So our client reached out and asked what would be involved in setting up an API. As some of you may know, this is an opportunity where a web development firm can fleece an unsuspecting client. Setting up an API normally means creating a secure layer where something like an OAuth 2 authentication is required. Additionally, API's often include both read and write capabilities. Additionally, API's sometimes include an e-commerce component where consumers of the API must pay a subscription fee to access it or perhaps pay for overuse of the API end points. Lastly, any API must have a tracking component built in. You need to know how the API is being used so that you can refine it as well as scale it in the right directions.

We don't fleece our clients. In fact, one of the principle values in hiring Solspace is that our problem solving always rests on a dedication to practicality. We build only the minimum delightful product. We revise and refine over time based on feedback. This means we help our clients spend exactly the time and money necessary to serve their customers best.

So we were called upon to set up an API for this product directory. We knew from the client that in the beginning there would be only a handful of consumers of the API. We needed to password protect the API, but we did not need to support an extensive authentication layer to get this. Additionally, the client, at this early stage, did not need to charge for access to the API so there was no need for an e-commerce layer. The API was never going to be a read / write application. Instead it was merely going to support browsing and searching across the product and certification database.

In order to support the above all we needed to do was create an API endpoint in a normal ExpressionEngine template. To support both browsing and searching, we fed the data through our Super Search ExpressionEngine add-on. And because there were only about five consumers of the API in the beginning, we simply password protected the API url behind Basic Access Authentication. Don't overbuild.

This approach got up and running pretty quickly. The ExpressionEngine template was set to output simple XML. The consumers of the API would parse that XML and use our data however they saw fit. But once it was running for a few months the client realized they needed and wanted to track usage. This was another place where one could overbuild a system. You need to strip the problem down as far as you can to the core components. You need to really listen, listen well, and extract the fundamental business needs. In other words you need to do the complex work of simplifying. Once we did this it became clear that a next simple step would be to use Google Analytics.

Google Analytics tracks all sorts of usage on websites. But wouldn't it be great if it could also support the tracking of usage on an API like ours? We couldn't use the usual GA Javascript because or output was an XML feed. Javascript wouldn't fire here because our API consumers were writing server to server connections to harvest data. Fortunately Google saw us coming. GA has a system called Analytics Measurement Protocol. This is a system that allows for a server-side API connection to Google Analytics. It was built and released mainly for mobile application tracking, but you can also use it to track API stuff like we were working with.

So we already have ExpressionEngine running and playing nicely through an API connection to Salesforce. We have built our own API for outgoing data consumption. Now we need another API integration to talk to Google. Since we already had a module running to support the Salesforce integration in ExpressionEngine, we just piggy-backed on that. We added a few tags to that module so that we could invoke the Google Analytics API connection in an ExpressionEngine template. In fact, this approach gave us a new opportunity. We could require that every url, every request to our API, include the username of an API consumer. With this username we validate that they are allowed to use the API. We block them otherwise. And with this same username we track their usage against Google Analytics. We simply assemble the data we care about tracking for each API hit, we connect to Google programmatically, we send the data, including the username of the consumer, then we close the connection and carry on.

Yes, if someone somehow gets the username of another consumer they could pretend to be that organization. The client doesn't care at this stage though. We're trying not to overbuild. And here's a good principle of not overbuilding:

"You don't have a problem until you have a problem."

Until we actually detect abuse or get complaints, we need not overbuild the thing.

Step by step, gradually and prudently, with a dedication to practicality, we have built up a pretty cool API for a valued client. As business needs demand it, we will build up further to support their needs. But until business needs absolutely demand it, we're going to keep it simple.