Requirements for Resellable Service APIs

Pierre D. Wellner
AT&T Research Laboratories
pierre@research.att.com
April 1996

Commercial services on the web

Large numbers of commercial services are appearing on the web. Most web-based services today are aimed at end-users who use standard web browsers, and many of them are supported by advertising to those end-users. In the near future, however, we may begin to see many specialized web-based service providers that each provide specific services for a fee -- not only to end-users, but to each other and to third-parties for the purpose of integration and resale to end users.

Imagine, for example, a brokerage company that provides an API for trading stocks, and imagine a separate financial information company that provides an API for retireving and tracking financial data. Each company might provide an end-user interface that highlights its own service but also provides access to the other. A third party might provide yet another interface to these services that integrates them differently and adds special analysis tools for a particular niche market.

It is possible to imagine a great number of services that might be made available for reselling this way, e.g. insurance, travel, teleconferencing, software sales, etc. Today, as service providers decide how to design web-based APIs for resellers of their services, they must take into account existing standards, the needs of third party developers (who may need to integrate several different services), the particular requirements of the service, and its end-users. Many of these services will have similar requirements, so eventually a standard set of technologies and/or conventions may emerge that is used by a number of different and/or competing services. In the meantime, however, each service provider must design its own technology for its APIs while we wait for standard approaches to appear.

The requirements below are based on experience with developing a web-based commercial service that is currently aimed at end-users with standard browsers, but which could potentially be offered to resellers through an API. What follows is a discussion of some important requirements such an API would have to meet. These requirements are not unique to any particular service but are common to a large class of services.

Asynchronous communication

Some services require that users get immediate updates on the state of their data as it changes. HTTP's RPC-style GET and POST are not well-suited for this requirement. Our current CGI implementation gets around this by using the "server push" browser feature with multi-part mime documents. This approach works but has some serious disadvantages, notably that every change requires updating the entire page, even when only a small part has changed.

Firewalls

A problem faced by any new Internet protocol is that it may be blocked by firewalls. Our current web-based system only uses standard HTTP and SSL so it can be used from anywhere a web-browser can be used. Recent firewall technology may avoid this problem, but some businesses must add a new proxy to the firewall for every new protocol. What are the best ways to make this easy?

Encrypted communication

Many service customers and resellers need to keep information about their transactions private. SSL seems to meet the requirements for this, but how easy is it to integrate with new APIs?

Support for billing and payments

It must be possible to bill resellers and/or their end users for service. This could be done through an account that requires registration, billing to credit cards, calling cards, phone numbers, or some other kind of electronic payment. High value services are favorite targets for fraud and require extra precautions.

Multiple users

Multi-user services must provide an API that allows simultaneous access to the same data from multiple clients. Clients may require different views of the same data and the API may need to enforce different levels of access permision to each client. This API may also need to be integrated with shared applications such as shared whiteboards, text editors and slide presentation viewers.

Programming languages

Applications will typically be written in C, C++ or Java. In addition to meeting all the requirements above, the API should be usable from all these languages.