11436 SSO

Field Notes: API Architectures for E-tail

mgardner
Mar 13, 2014

In a previous Field Notes post, “E-tail, Data, and the ‘Smoosh’,” we discussed how the convergence of retail and ecommerce among our customers exposes a variety of data that can help create the kind of experience that consumers have grown to expect. APIs are a critical part of the equation, as they help shape, control, normalize, and transform the data.

Here, we’ll examine the API architectures that implement these APIs.

The two-tier API structure

Typically, APIs will be structured in two tiers, which Apigee tends to generalize as being a “consumption” tier (having a set of APIs that are friendly to application developers and enable rapid development and iteration of consumer- or user-facing applications) and an “exposure” tier (publishing data from a back-end entity, or writing back to it, and unifying any number of disparate back-end access mechanisms and protocols).

There could be just one API tier serving both purposes, but for various reasons it’s usually better to split them apart. Perhaps most importantly, this allows a change velocity gradient, so that the front-end APIs can evolve and grow in ways that maximize app development velocity, while the back-end exposure API can change more slowly, and with less wear and tear on the underlying back-end systems.

Consumption APIs

If we look at the front end and apps, there’s a mix of device and consumption platforms, running web browsers or apps. Here, the trick is to allow the data interaction in ways that are friendly, even “tasty,” for app developers (part of the challenge in app development these days is recruiting or convincing the best app developers, and it’s a buyer’s market).

The front-end system must also be able to accommodate rapid evolution in the APIs themselves, and perhaps even multiple API sets focused on particular market sectors and usage populations. These “consumption” APIs allow usage of the data/services made accessible from the backend.

Consumption APIs are usually REST, so as to be most useful, for example, by software development kits (SDKs) for app development on iPhones, Android phones or tablets, and other devices. This has certain implications for the format and structure of the API calls themselves, but it also has implications for how the APIs are described in metadata (for example, JSON rather than XML) and for how data is passed through the APIs as payloads in requests or responses.

Enterprise back-end resources

IT probably figured out a long time ago how to make sure the legacy back-end systems are talking together in the right ways, and is probably grappling already with new big data technologies (HBase, reduce technologies, and so forth). But IT can only evolve so fast, and is typically backlogged and facing budgets that are frozen or increasing only incrementally. Plus, change is the enemy of availability.

For these reasons, most enterprises end up with APIs that allow uniform access to the backends, but are also basically change “shields.” Need a REST front end, but stuck with a legacy SOAP or SOA backend? No worries: create an exposure API that will transform between the two and offer a consistent programming interface to get at any back-end service, and you hardly have to make any changes at the backend. This makes things tolerable for IT, but doesn’t prevent the business velocity necessary at the front end (that said, it doesn't enable that velocity—that’s what the consumption APIs are for).

So now let’s go back to the user requirements for e-tail and the need for consistency of experience and portability of information and context across multiple “channels” of interaction. This is necessary to enable the user experience, constant connection, and specifically targeted relevance that is necessary for commerce these days. You can see that this two-tier API architecture suits the needs well. The same or similar APIs are used to shape the interactions—it’s all the same data, it’s just the interfaces that are different, depending on what is most relevant for the user state at any moment.

In the next post in the e-tail series, we’ll explore how this basic pattern plays out in some specific sectors.

 

API Management Decision-Making Kit

Next Steps

 
 

Resources Gallery

News