My Love/Hate Relationship with APIs
by Matt Heusser

Ten years ago I was a programmer working at an insurance company. The hard IT work of an insurance company is claims processing - taking in new members, getting claims, figuring out how they should be payed, and paying them electronically. That meant a big database.

We wrote a lot of SQL, the programming language for databases. When our claims processing vendor came in telling us about Service Oriented Architecture, we yawned. Instead of a hand-rolled SELECT statement, something like this:

SELECT member_id FROM members where first_name="John" AND last_name="Smith" AND birthdate = "1/1/1990″;

We instead would have to code something like this:

<Query type="select" table="members" where_ first_name="John" where_last_name="Smith" where_birthdate="1/1/1990″>

From what I could tell, the middleware would take the XML, make my original SQL query, call the database and return the same results. So a more complex implementation that takes more processing for the same results. I was not impressed.

Today I see that first introduction as a terrible one - a vendor chasing a buzzword, not a real problem to solve. And I do see API's solving some problems - and creating others. The question is which problem you'd rather have. So this is the rest of my story.

Entering Socialtext
From the insurance company I went to Socialtext, making web-based, collaborative software from home for a Silicon Valley Started funded by Draper Fisher Jurvetson, who also funded Twitter, Skype, Yammer, SpaceX, and Tesla Motors.

Talk about your culture shock. The biggest technical difference I noticed between Socialtext and the insurance company was the architecture. Major business functions, like search, adding or deleting a tag from a page or profile, search, and get text for a page were all driven by REST APIs. Once authenticated, you could calculate the URL, pass it in like a web page, and get JSON back. The read-only pages didn't even require authentication, so you could type:

http://www.socialtext.net/data/workspaces/help-en/pages/Searching?accept=json

Right into the browser, hit return, and see the raw text. Go ahead, try it yourself. The accept=json bit gives a format, JSON, that is easy for computers to read into an object. Drop it for a more traditional HTML rendering.

After I checked the results by hand, I could save them in a text file, then write a tiny bit of code to hit the web service and compare it to the expected results.

Adding authentication is trivial; here's a simple python example using a library called requests:

r = requests.get(‘https://www.socialtext.net/data/workspaces/software-delivery-24-7/pages/scrum_for_testers?accept=json', auth=(‘[email protected]', ‘mypassword') )

print r.status_code

print r.text

We ended up writing code libraries to make this even easier. The typical pattern was load up a known workspace and check the read qualities, but also to perform logical operations. So, for example, search for users tagged ‘Smartbear', do not see Matt Heusser, add tag Smartbear to Matt, search again, see Matt, delete tag, search again, do not see Matt listed and so on. Exercising the API was incredibly fast, easy, and allowed us to figure out if the problem was in the graphical front-end or the back end very quickly.

That was all good, until about a year past, and suddenly users asked us for mobile and desktop versions of our software . This was back when a "mobile version" of a website meant a total rewrite.  I braced for the worst.

Reskinning the Interface
Most of the work in building an application is on the back end; prototyping the user interface is the easy part. By having a solid API, we had actually turned the back-end as a reusable component. The developers at Socialtext had a real-only version of the mobile website up in week, and a major buildout of functionality in two sprints - four weeks. Audrey Tang took one large piece of functionality, called Socialtext Signals, which was sort of for-inside-a-company-only version of twitter, and wrote an Adobe Air Application in three days! The teams also yanked functionality out of the web-based application, from workspaces to profiles to signals to display a page, and put them on "widgets" they you could drag and drop for form your own personal dashboard.

Here's four examples of signals, on a phone, as a webpage, in a desktop application, and on a dashboard.

At the previous companies I had worked with, each of these would have been a new project, if not an entirely new team, to build new, redundant technology, to essentially do the same thing.

When Matt met SOFEA
After Socialtext, I went to work with a large wholesale company doing an ambitious ecommerce project, instead of listing their products on a partner site. The team used something I hadn't heard of called a SOFEA, which stands for Service Oriented Front End Architecture.

With SOFEA, there is no back end; no java, no C#, no PHP or ASP.NET. Instead the application serves up static web pages that contain javascript. The Javascript makes API calls to the back-end - login, search, production description, add to cart, and so on. The Javascript takes the result and creates HTML - for example, looping through a list of search results to show products that contain "chicken wings."

We could us the developer toolbar to see exactly what values pass over the wireless - what queries were made, what the results were, and how long they took.

The eCommerce project was split into two groups, with front-end developers and back end. This allowed people to specialize in one area or the other, which made it easier to hire.

Matt added the tag "testing tagging" to a Socialtext page; then the software made calls to re-order the tags alphabetically and redisplay.

That also had drawbacks. The front-end typically a sprint ahead of the web services, so we would test a User interface that didn't do anything yet - and often could not release because the front-end for a feature was done but the back-end was not. This made us lose the customer perspective of one feature, instead thinking in "feature halves." Also, if a tester filed a bug, and didn't indicate where the problem was, it would be bounced back.

Neither of those are really API problems, and they are solvable. We could have hid non-active UI elements with config flags turned off, and paired front-end and back-end developers to run a story end-to-end. Still, it didn't excite me.

It was during the ecommerce project that I first really got to use SOAPUI, as a sort of non-code version of the python I mentioned above. SOAPUI could store and handle login credentials, could keep a list of URLs and expected results as a "test suite", but best of all, it allowed me to experiment with different input values quickly, by changing the URL, looking at well-formatted results (JSON can be hard to read), taking what I learned and trying something else.

The Third Time May Not Be The Charm
On the next big project, we had grown over years. One of the features was a small API, but the entire application was designed as a network, where anyone could meet anyone and develop a business relationship. That meant the whole application was one big database. The Development and Test databases were Terrabytes in size, and no, it was not possible to have a copy of the database, even a tiny one, for your own personal use. That meant stale data, shared user accounts, and  no easy way to make setup/test/teardown happen.

We could have set up some sort of service virtualization - to simulate the API with known, canned results, to test applications that used the API - but the API itself was extremely brittle. My lesson was that a good API by itself my night be enough to make a project sing.

One More Time, with Flair
At the insurance company the real problem wasn't figuring out a member id; it was figuring out if a member had coverage at a specific time. After far too long hand-rolling the same type of lookup over and over again, I wrote a bit of code to figure that out for me and put it in a code library. That's an API of sorts, and it did lead to code re-use. If the software vendor had only done that - enabling real business processes, not just wrapping table lookups in XML ... I might not have been so opposed to it in the first place.

So if you're creating an API, don't chase buzzwords - help your partners solve problems. If you a technical person pushed to use an API, but don't see the value, that's okay. Despite all the pressure, they aren't going to pick up a keyboard and write the code. They need you.

You get to do what makes sense.