At the time I was working for a large retailer in the entertainment business and putting together a mobile strategy to leverage our existing assets and systems. Ultimately, I was trying to make it easier for our customers to transact. Too many times customers would enter the retail locations and ask for a product only to be told it was rented out or out of stock. I knew for a fact that the product was somewhere in our supply chain, I only needed a way to get it to the customer.
Initially I thought that the ability to look up realtime inventory at the POS would be a good first step. At least we could locate the product in another store and then hold it for the customer. Better yet, we could make the inventory levels available on our website and iPhone app. Itʼs called "trip assurance" in the retail business; a very nice customer convenience. All this information is good, but how does the customer pull the trigger and transact, and actually get what they want?
The answer was right there in front of us. Transact in one channel and fulfill from another channel. The old endless aisle strategy. Use your e-commerce inventory to fulfill demand in the brick and mortar stores. The opportunities were endless - we also had kiosks and digital delivery.
We decided to leverage our e-commerce channel as the platform for the future. We built everything to be reusable. We built the foundation using an API.
Originally I was barely able to search my memory for the meaning of the acronym. An Application Programming Interface. An interface that can tap legacy and modern systems alike, an interface that offered a clean read/write function that could be reused from any and all screens.
We set out to build our API as a means to an end for our mobile strategy. But when we started to blur our vision, we saw something new: inventory, orders, payments, items, price, promotion, fulfillment. It was a point of sale. We discovered we could build our next generation POS by leveraging our new retail API strategy.
Mike Debnar is VP of Business Consulting at Sonoa. He comes to Sonoa from Blockbuster where he led the retail systems organization as Vice President, working closely with operations, merchandising and marketing to implement the company's multi-channel retail strategy.
In our daily talks with customers about their APIs, OAuth has become a major consideration. It's quickly replacing the various proprietary "authentication token" schemes used by early APIs (such as the Amazon Web Services APIs) with a flexible standard; and it solves for new use cases emerging from mashups and Web 2.0. Still, there is a lot of confusion about OAuth out there.
Based on the current state of the technology, we know that there are different API use cases. Depending on your security needs, sometimes OAuth is the only security technology an API can realistically support. In others cases, it may be overkill, or something to add alongside another scheme.
OAuth Overkill?
OAuth is overkill for an API that doesn't require strong authentication. Many "catalog" and "search" APIs that access public data fall into this category. The goal of an API like this is to gain adoption. There's no reason for such an API to require individual users to authenticate to retrieve information from a product catalog, or search public data. (Unless, of course, your API's business model revolves around data that is so valuable that you can get away with charging for every data access. In today's world, that's not common.) A simple API key, however, is a great idea for these kinds of APIs, integrated into your API analytics so you and your developers can see what's going on.
The Case for OAuth
OAuth is the only realistic choice for a web application that itself uses another web application's API on behalf of the user. For instance, consider a web application that integrates with Twitter. (Perhaps it's a geolocation app like Foursquare that offers the ability to tweet where you are and what you're doing.) Today, it is unacceptable for such a web application to store its users' Twitter passwords. OAuth was designed precisely for this use case -- it gives the web app a secure way to get an access token for Twitter, which the user can revoke at any time, without ever revealing that Twitter password to the web app.
Basic Auth- Still Important
In most cases OAuth should be one of two or three security choices for most APIs. Again, consider Twitter. It makes perfect sense for OAuth to be used by other web apps as a way to access Twitter. But Twitter has long supported "Basic" HTTP authentication as well, using a username and a password. While this is bad news for a web application client, for a mobile or a desktop client that is used by an individual user, it's just fine as long as the client takes some care with the password.
And importantly, Basic authentication is easy. If your API requires secure authentication, and you want it to be easy to integrate and test, then offering Basic authentication means that the barrier to entry is low.
Now, once the decision to use OAuth has been made, the question is whether to use the current version 1.0a, or the still-under-development OAuth 2.0. We'll talk about that next.
Facebook and Twitter are cache assembly lines -- every web page and API request is served up by many calls to various caches at different levels - assembling the final result from many different chunks. At this scale there is almost no other way to deliver reasonable performance.
For APIs - what's the largest chunk of all? The entire API response.
APIs lend themselves nicely to caching responses because it is often easy to identify the cache key. If you follow the REST pattern each URL maps uniquely to a resource that has a well-defined lifecycle.
If you're working on the next Twitter, you will need many layers of caching to deliver great performance, including the filesystem and database caches, and then you will add additional caching layers using products like memcached or Coherence. But a final tier of caching for the API responses themselves can only help performance, so consider:
Can API analytics data show the most common or slowest API calls?
Are there slow API calls that return the same data over and over?
Can you design using a REST pattern to make it easy to identify individual cache items?
There are a number of ways to speed up calls that are caching candidates, such as memcached or something similar.
Another way is to use an API proxy. A proxy that is sitting in front of your API servers is an efficient and easy way to add an additional caching layer without making any changes to the server tier. We have helped a number of customers drastically improve the performance of their APIs by inserting such a caching tier without touching the clients or servers.
And caching isn't just helpful if you are building an API. Applications that consume APIs, whether they are running on another web server or on a smartphone, can set up their own API proxy so that responses from many devices are cached in a central place, even if the APIs that the application is depending on can't be depended on themselves to return good performance.
We've seen an architectural pattern emerge over the last two years that deals with the expanding variety of computing devices and the exploding number of APIs used in modern applications. This pattern is API Virtualization - applying a virtual layer above the API itself to deal with the different concerns that come into play when delivering an API to different device and machine endpoints as well as across a range of different classes of business relationships.
Sam Ramji gave this presentation at GlueCon as a Prezi. The prezi is available here, and we've put the audio with it in the screencast below.
One of the big shifts that has occurred in application development is the move from libraries to APIs for use of pre-written code. APIs enable access to not just logic but data and the the computational power required to render that data appropriately. The Facebook and Twitter APIs are good examples of this, but there are many more including Paypal's X.com, Ebay, Amazon, Netflix, Sears, Blockbuster, Best Buy, MTV and Google.
While applications like Siri which use 20 or more web APIs are still unusual, most applications use several APIs to deal with access to content, social networks, events, identification, payment, and other concerns. These APIs change frequently, as do the applications that consume them, resulting in a web of dependencies and causing chaos in the development lifecycle.
API Virtualization enables these different concerns and dependencies to be isolated from the application or API provider, resulting in a cleaner development process and higher-performing applications.
What do APIs have in comon with Darwin's observations on evolution, the 20th century garment district, and the Kobayashi Maru?
Sam Ramji makes the case for APIs in his much written about web 2.0 talk - watch and listen to the full talk or just flip through the slides - both below.
Highscalability.com