Today's websites and web applications are becoming more and more powerful and prevalent – but at the same time, we are beginning to see movement away from “the web” as a primary means of interaction with end users. This is particularly evident when looking at the smart phone market – instead of relying on “mobile sites,” many organizations are choosing to leverage native apps that can provide a clean, optimized, and reliable experience. This is a trend that anyone developing web-based services simply must recognize – the question is, what impact is it going to have?
To answer that question, we have to dig down to the basics. One of the “golden rules” of software development is known by the acronym DRY: that is, “don't repeat yourself.” This principle is pretty simple, and it's exactly what it sounds like. When writing any given code, it's in everyone's best interest to ensure that it only needs to be written once: for devs, it means less wasted time and effort, as well as fewer opportunities for bugs; for clients, it means less cost; for end users, it means more consistent behavior.
So when designing and developing a system that will be accessed via the web, mobile app, and possibly even embedded device, it's important to recognize that a solid, shared “core” underlying each of these “endpoints” can be a priceless asset. This core layer provides processing, storage, etc., and enforces a common set of interfaces that can be used in various ways and by various devices. A term often applied to this type of architecture is API or “application programming interface.”
There are a number of very real benefits that come along with developing an API for your system. One of the most important aspects is, by starting from an abstract level, it's possible to clearly and cleanly define the structures and processes that will be needed. Instead of being distracted by how things might be presented or managed “on the screen,” the focus here can be on the precise expectations of the system.
This extends to helping ensuring that aspects of the system are generally modular – that is, each part can be designed and implemented with minimal reliance on the other parts. This means that different bits and pieces can be more easily added (or subtracted) without having to drastically re-engineer other parts of the system.
A specific consequence of this modular design is the separation of the front end from the back end – referred to in some spheres as a separation of “presentation” from “logic.” That is, we ensure that all the heavy lifting is done behind the scenes of the API, and all that our user interface needs to do is handle the inputs and outputs in a clean, aesthetic fashion. By taking this step, we can ensure that changes and/or upgrades to either the processing OR the interface can be made completely separately from each other. It also helps with cross-device work – porting that interface (e.g. from the web to a native app) doesn't have any serious implications on the actual behavior of the system.
Of course, developing around a core API is not a magic bullet. One of the biggest issues, of course, is that of the requisite investment, both in time and money. This is not an unreasonable concern, and it is true that (usually for smaller or simpler systems) building out a full-fledged API layer may be unnecessary or even undesirable. However, even these smaller systems may benefit from the easier maintenance and scaling that an API can provide.
Similarly, there are questions of security: exposing “raw” interfaces that could potentially be accessed in an unintended fashion can seem dangerous at first glance. However, the same authentication “best practices” that are applied to any web service can certainly be applied to an API – and what's more, the granular and modular nature of these interfaces can even provide for more precise security with less headaches for your developers.
Before diving into developing an API, it's important to know what sort of framework(s) will be used. There are a number of possibilities, ranging from the tried-and-true to the new-and-exciting.
Many older systems rely on a SOAP (Simple Object Access Protocol) or XML-RPC (Remote Procedure Call) layer to handle interactions. These are based on XML messages, and have a lot of support in legacy systems. However, they rely pretty heavily on precisely-structured endpoints (for both the server and client) which can make rapid improvements and changes difficult.
To avoid some of that complexity, many newer systems make use of REST (REpresentational State Transfer). By using JSON messages between client and server, and leveraging the built-in functionality of the underlying HTTP layer, REST keeps things fairly straightforward, though occasionally making complex data structures and objects a little bit tougher to transfer.
In most cases, decisions about what sort of frameworks to use will rely very heavily on what sort of existing architecture is already in place. In the absence of compelling factors, however, we often recommend a REST/JSON system, due to its immediate compatibility with multiple systems and its well-defined semantics.
However big or small your project may be, it's definitely worth considering an API-based paradigm by consulting with the experienced Smart Software team. We'll help ensure you're able to make informed decisions about how best to build one of your organization's most important assets, and that your systems are implemented in the most robust, scalable, and secure way possible.