Why CTOs Need to Think About APIs Before Websites

By moving the primary focus from your website to your API, your organization will be far more prepared to thrive in the mobile revolution.

I came out of college right at the exciting explosion of the web. Most people paid little attention to it, Wired looked like this, and my family would get excited when they saw a URL in a TV ad because that was that web thing that Brant worked on. As business models began to solidify and we shook off the cruft of the exploding bubble, businesses started paying real attention to the web.

But we may have been too successful. I now find many organizations with their data and servers so structured for their web concerns that they have no way to expose that to their mobile apps.

The first year I worked with one large retail business they had no way of making appointments from their app. They had built this functionality into their website, but had no API to expose it to anything else. So, a major feature (and the biggest ROI driver of their app in the next several iterations) had to wait a year before it could be implemented. This was a frustrating problem in 2010 when it was ostensibly excusable to not understand the mobile surge. Now it’s simply unpardonable.

The solution is quite simple: focus on building a great API first, rather than your website. Here are four reasons why it will make you more nimble and even make your web presence better: 

Future Proof

In 2007, hardly anyone would have thought we’d be where we are now – millions of apps on the app store, tens of billions of downloads by a user base larger than we’d ever had with desktop PCs. However, if you had a solid API in 2007, you’d already have been ready for this.

By thinking first about your API, you remove the particulars of what connects to it. It could be a web browser, mobile app, or devices we’d never even recognize as internet capable today. If you instead look only at a website, you will constrain your vision to a subset of the possible connections and limit your usability.

Separate business logic from presentation

Another benefit of shifting your focus from a website to an API, is that business concerns are elevated away from UI concerns. A website naturally must think about the ways in which customers will use it, making things like the way it looks and which page leads to which major concerns. An API is free to operate on a purer level, representing only the concerns of how pieces of the business function.
This means that you can change front-end technologies without having to effect change in the core business code. For instance, you could have a consumer-facing web front end while having a dedicated mobile app for inside the company. Two applications with different flows and user experiences, but with one unified and more easily maintained core of code at the API.

Easier, cleaner testing

By separating out user-facing technologies and focusing on the API, you can then directly test the actual calls themselves. It is far easier to write automated code to interact with an API than a website.

In addition, it allows changes to be tested separately. Let’s say you needed to completely change the database architecture of an API vs. a website. If you have an API with fully automated tests, you can swap the server, run the tests, and fix errors until you’re green.

Bugs are easier to find because you have an error in a specific call which maps to a specific function in the business. If this were a website, you’d first hope you had maintained the far more difficult automated scripts. When something failed, you’d have an error in a specific piece of the user experience, which you would then need to map back yourself and hope there wasn’t a UI assumption now invalidated by the change.

Address security directly

Security is one of the most significant concerns of any internet-facing corporation. It is perhaps a special case of the previous point – insecurities comes from bugs. It’s a huge concern that could have large-scale ramifications for your business. Certainly, having a more easily testable, auditable, and reusable API is a benefit.

But focusing on APIs bring additional security benefits. With an API, you are separating different layers of your app. There’s a whole host of security issues that can sneak in when the UI is directly coupled back to core functionality.

Let’s say I have a service that allows people to log in. I limit the number of login attempts in the UI, but I forget that someone could still script the submission while ignoring the UI-enforced limit. When the login API is separated out, this concern is elevated and handled the only place where it can withstand this attack: the server.

Organizations that want to be ready to unlock the full potential of all the various platforms now at play in the mobile revolution must shift their focus from websites to APIs.