How to expand your API strategy
Application programming interfaces (APIs) are expanding ecosystems and market presence for large services like Google Maps, Lyft and Facebook, and they have created new market channels and products for traditional players including Pitney-Bowes (e.g. location-based information services), Capital One (bank accounts, credit card offerings, rewards etc.) and the Chicago Transit Authority (e.g. transit tracking and notifications) – and many more.
The reason leading enterprise architectures (EA) adopt REST API strategies is because REST helps extend ecosystems, increase market presence, and create new products, revenue streams, and interaction channels.
REST APIs have become a shiny object. Too often in our API strategy discussions with customers, the goal is “implement REST APIs”. But the real business goals are to optimize experiences, operations and collaboration with customers, partners and other actors in the ecosystem. REST APIs are just one technology for that.
The better strategy framework is the digital connection, which Forrester defines as any type of collaborative connection—company-to-company, person-to-person, or company-to-person—enabled through the connection, communication, or use of one party’s software becomes third-party software. However, REST-only strategies do not cover the full range of business relationship dynamics.
The normal synchronous request-response mode of REST APIs is just one of the ways companies connect their own applications. So why should this be the only way to connect with customers and partners? Answer: It shouldn’t be. EA Pros should take their organizations beyond REST APIs.
Digital connection beyond REST
Digital bonding includes both new and traditional mechanisms for connecting across company boundaries. Predecessors of REST are still in play, including B2B portals, Electronic Data Interchange (EDI), SOAP APIs, and MFT.
WebSockets and GraphQL are newer options that go beyond the capabilities of REST. WebSockets provides bidirectional, stream-based communication between software components, enabling a variety of real-time flows of information, events, filtered data streams, and more. GraphQL provides query-based access to a collection of related data schemas, allowing API users to navigate the data at will.
Importantly, both are gaining support, albeit slowly, from API management solutions and API gateways. Events are also being published on protocols such as WebSockets and Webhooks, and brokers such as Apache Kafka. Early examples of companies adding WebSockets to their digital engagement strategies include market data and messaging, while GraphQL has broader vertical usage.
For example, Slack uses WebSockets to keep conversations flowing. With its real-time messaging API, a program can receive a continuous stream of instant notifications from Slack’s messaging infrastructure. A developer configures the stream to connect to a selected conversation channel. Whenever something related to that channel happens, Slack sends a message over the WebSockets connection. The developer decides which messages are interesting to act on.
Slack also offers its Events API, which instead of maintaining a long-running connection, sends selected event notifications one at a time, e.g. B. when checking in new code starts a project build process.
Another example is how multiple vendors provide market and cryptocurrency data through WebSockets. One of these providers is Refinitiv with its market data platforms Enterprise Platform and Elektron Real Time in Cloud. Refinitiv supports WebSockets for both delivery and publication of market data.
For cryptocurrencies, developers connect to the Kraken or Coinbase WebSocket feed and select specific channels to access various data flows on orders and trades. These allow developers to subscribe to data for specific currencies and build/maintain order books – all without even authenticating to the service. Coinbase also allows developers to see individual orders as they are being placed and authenticate to the feed to get deeper data about their own orders and trades.
Gemini Trust Company, CEX.IO, and others offer similar WebSockets feeds.
GraphQL offers another way to achieve digital bonding. GraphQL can be used to provide data access in application areas such as e-commerce, healthcare, science and travel. Although GraphQL is finding early public appeal in a wider variety of industries than WebSockets, many offerings are marked as experimental, beta, or otherwise in development.
They all offer flexible access to some kind of dataset. For Deutsche Bahn and the Helsinki Regional Transport Authority, it is public transport data (e.g. timetables, routes). For travel and entertainment, there’s TravelgateX, Universe, and Yelp. There is geospatial data (e.g. GraphLoc, Country List), health data (e.g. Stanford University HIVdb), chemical reactions (e.g. Catalysis Hub), development tools (e.g. GitHub, GitLab), professional data ( e.g. Mattermark, LeanIX), and Holocaust archives (e.g. EHRI).
Braintree goes beyond just query data access to provide payment transactions via GraphQL, as do Commercetools and Shopify for shopping carts and other ecommerce data.
WebSockets and GraphQL are just a start to go beyond REST. In addition to looking back at traditional mechanisms, enterprise architects developing enterprise digital engagement strategies can leverage newer and emerging mechanisms such as web components, eventing (e.g., AsyncAPI, CloudEvents), and streaming. Some mechanisms may use new technologies or protocols, some may use old technologies in new ways (e.g. application messaging, MQTT), and some may be patterns for using REST APIs.
But the point is to let the business problem – not the technology religion – dictate the style of digital engagement mechanism used.
Extension of integration prospects
REST APIs are all the rage because they have a certain simplicity. However, some business scenarios require different interaction models or richer semantics than REST can provide. If you’re intercepting a stream of data updates or continually polling to verify that an event has occurred, REST is cumbersome at best and can be expensive and hamper scalability.
As an EA leader, you need to remove any REST blinders you may have. Open the door to innovation and opportunity by thinking, speaking and designing in terms of the “Virtual Enterprise” – as if your organisation, your customers, your suppliers and other stakeholders were running a process within an organisation.
Start with known issues and desired business outcome improvements—but don’t limit yourself to those. Invent new problems, new potential outcomes, and even new business models. Ask how each party can add value and what drives data, processes, events and transactions to flow across organizational boundaries.
Refine ideas before allowing value analysis to triage and prioritize opportunities.
This article is based on an excerpt from Forrester’s Digital Bonding: Expand Your API Strategy Beyond REST APIs by David Mooter with Chris Gardner, Caroline Bonde and Kara Hartig. The Forrester B2B Summit takes place in London on October 11-12.