Making API Experience a Project Priority

WRITTEN BY: DANNY BAGGETT, LEAD ENGINEER, BOTTLE ROCKET

In a past article, we gave a best practices breakdown on flipping API development upside down for top-down development with quality API design that delivers functionality consumers truly need. We believe APIfueled mobile and web applications are a representation of the underlying APIs, so it’s critical to get the design right from the onset.

However, not all projects can justify completely overhauling APIs just to go top-down for a change. In fact, many projects start off in pretty good shape where the underlying enablement APIs are performing just fine and providing all the key functionality that the mobile or web experience needs. You don’t have to reinvent the wheel or implement some unnecessary abstraction API to start thinking about the experience given to your consumers.

An API Gateway is a great way to start adopting the experience mindset in APIs without doing a full rebuild.

API Gateways in general act as a proxy between consumers (mobile or web applications) and upstream APIs. Users of API Gateway products oftentimes have pre-built or custom policies at their disposal which can augment the underlying APIs to create something that may appear much different and hopefully richer. One such API Gateway is Azure’s API Management product which we used recently for a client’s native Android and iOS applications.

Upon project start, the client was already integrated with two established and wellequipped vendors in the online ordering and loyalty spaces respectively. Most of the features and functionality that were reimagined in the new native experiences were already supported from an API perspective in underlying vendor APIs. Still, we needed a way to maintain parity from an API perspective while also having the means to easily expand capabilities in the future.

With Azure’s API Management solution, it was painless to get an API Gateway created which proxied the underlying ordering and loyalty APIs. From here, we went on to tackle an awkward login process in the existing experience which required the client to authenticate with both the ordering and loyalty services. Using Azure’s policies, we created new registration and login API resources which handled the orchestration logic. This allowed the developers to interface with a single API while still having access to all the same data. An API Gateway is a good way to handle minor orchestration challenges such as those on the aforementioned project. In fact, a gateway should probably be considered standard practice for any large-scale API rollout due to the governance and security features alone.

You don’t have to fully reimagine your existing API ecosystem to make experience at the API layer a priority. Start making your consumers’ lives easier immediately no matter how small or large your initial deliverable needs to be.

It’s important to note that there are multiple ways to solve challenges like these. An API Gateway is one option, but there are others. The product or tool is not the ultimate takeaway from this experience. The most important thing is that an awkward and undesirable authentication process was not allowed to remain as an annoyance for consumers in the future. A stand was taken on this project to think about a consumer’s experience using the API. There was no wait for more meat on the bone or some new feature before acting. API experience should be an immediate priority no matter how small the effort.