When people refer to an API-centric web application, they usually mean that most if not all of the functionality within the app is executed through API calls. That means each system like your databases and your front end application can operate independently but communicate seamlessly. In other words, you can do things like build entirely new interfaces or plug into separate platforms just by using the API calls provided.
In case you’re unfamiliar, API stands for Application Programming Interface. For most SaaS products today, an API most commonly refers to a set of functions built into an application for use by other external applications, but increasingly companies also use their API internally.
At HasOffers, we don’t think of our API as just an extra feature. Our API is our core data layer – core to our business. This allows us to be consistently enhancing the API and regularly sharing those improvements with clients that use it externally.
Why API-Centric Applications Are Cool
For startups looking at building an API, I really recommend approaching your API as your data layer. It should be the first thing you think about as you are building your application.
Designing your data layer with an API in mind forces you to think about all the possible use cases for your data. It allows you to identify the business problems you need to solve, while also getting you in the mindset of thinking about how others may ultimately interface with your data, including potential partners you may find, or even the companies who may be interested in acquiring you.
Building your data-layer with an API has other advantages. You create a unified codebase that you can maintain for internal and external facing applications. There’s no additional work in opening the API, since you simply need a ruleset for who has access to which API methods. Ultimately, you can really increase consistency. Your web interface always returns the same results as other applications making API calls, because you’re addressing the data layer using identical methods.
I learned that we needed to build an API-centric application the hard way. Our original data layer wasn’t written with an API in mind. Our clients using the API had a limited set of features available compared to the universe of features built into our integrated web interface.
On top of all of the flexibility in functionality, using an API as a data layer really equips you to scale. You can even launch separate systems into cloud architectures, testing as you go. Once you have an internal API, you can easily add access controls and authentication processes to securely support external access.
Getting Your API Started
If any of what I’ve said has convinced you to use an API-centric approach to development, you can get started by building your API for internal use first. This really makes sense if your product is brand new and you have no reason to make an external API available to clients. I’d offer advice if you’ve already built your web application without an API. Start building it into your internal process now and eventually it will be complete enough to release for external use.
The first version of our API needed to encapsulate all functionality we already implemented in the application stack as API calls. When we re-wrote our data layer to be an API two years ago, not only did we have to re-write everything from the ground up, we also documented each API call throughout the process. If you have a large code base, as we did, documenting each call can be daunting.
Starting with an API also helps guarantee effective documentation. By starting with an API in mind, you document as you go, allowing you to grow and setting you up to launch a successful external API when you’re ready.
Our team just finished updating our API, making this the third full rewrite in three years. We updated it to PHP 5.3.10, increased data capacity, improved management of larger data sets, made our API requests faster and more efficient. We also updated the framework for the affiliate and advertiser APIs. You can learn more about today’s update in our press release.
I can tell you that this was no cake walk, but the HasOffers engineering team, led by Lee and myself, believe in building the most scalable foundation we can, greatly improving our ability to adapt to the needs of our clients moving forward. After all of this, I can truly say that our API is one of the major differentiating factors between HasOffers and any competition, which also make things easier for our sales and marketing teams. They understand the value of our API, communicate it to clients, and it truly gives us a huge advantage.
Need a new feature? Want to build your own custom front end? Need to integrate with anything under the sun? No problem 🙂
Lucas and his twin brother Lee began their first businesses before starting high school in their hometown of Elma, WA. They quickly found this world suited them, launching other successful businesses in college and reporting their first million dollars in revenue as sophomores in their dorms. Developing unique solutions for their own ad network, Lucas had the foresight to white-label their technologies to empower other businesses, which quickly became the birth of TUNE. As Chief Product Officer, Lucas leads agile product teams that strive to quickly meet the needs of an ever growing client base. As a founder, Lucas and his twin brother Lee supported the company in the beginning, growing to profitability by 2010. Lucas’ expertise in complex business models, integrations, implementations, and his constant drive for innovation make him a cornerstone of this Seattle based startup. Lucas graduated from Babson College in Boston, MA.