APIs and the Channel of 1

APIs, like USB ports, ensure that service requests are sent to the right place, the right endpoint. And similar to USB, the API requests to services are managed to assure IT that those services aren’t overloaded, that inappropriate requests aren’t made of them, and so on. They ensure that the request from the app on your phone gets through. And they also assure what comes back – the response – and hence what you see on your phone’s screen. This is often overlooked.

What do they send back? Tersely, the response, as appropriate, to the request. A “get Location” request would be submitted with a subscriber’s phone number (say). The response would be their current position – expressed as a latitude and longitude (and ideally street, GPS coordinates, postcode). The API gateway can simply provide this response – as is – back to whomever requested it. Or it can do things with it.

The first thing we can do is to hide bits: to mask over some of the data in the response. Take the “get Location” example above, and let’s assume that the response from the service includes lat-long, street name, GPS co-ordinates AND postcode – it’s a very complete service. We could then provide multiple versions of this service with varying levels of quality. A basic version might just provide lat-long, but a more complete version would provide GPS coordinates as well. The super-duper version provides street name and postcode. These differing levels of response detail can be viewed as different levels of quality for the “get Location” service. This ability to hide or transform the response also permits us a quick way of implementing basic data privacy. It takes a lot of pain away from certain apps if these additional views on location are provided, so people may be prepared to pay for this. And sometimes they do.

The other thing we can do is put bits in: for a given request, we can add fields that contain things we want to send to them: adverts, images and videos, offers, coupons, updates. These added contents can be used to support the organisation’s broader aims: to entice customers with relevant and pertinent advertisements (a goal of 1-to-1 marketing); to pre-empt employees with information on their next job, next task, next delivery; to provide a means of notifying users irrespective of what they’re doing. That this activity can be decided upon using information from the gateway itself (see previous blog) and can be decided in real-time (it takes a few hundred milliseconds to make these decisions; it takes about the same time for a response from the service layer), without impacting the services’ operations or the users’ experience.

One area this second option differs from precision marketing is that the request/response mechanism is in direct contact with the app, the phone, the user. I know their device, their IP address. This provides the basis for analysis of that user experience and how it might better be configured. Now I can get analysis on the content, on the impact of an advert, because I can see when they got the response and whether they clicked on it, and how long that took. I can adjust the content I send based on time-of-day, locale, network bandwidth, screen type, OS: all to best address the immediate user experience. It’s a way a business can simply connect to each customer or employee, over a channel of 1.