[ad_1]
Application programming interfaces (APIs) expand ecosystems and market presence for major services such as Google Maps, Lyft and Facebook, and they have created new market channels and products for traditional players including Pitney-Bowes (location-related information services, for example), Capital One (bank accounts, credit card offers, rewards, and so on), and the Chicago Transit Authority (transit tracking and alerts, for example) – and many more.
The reason enterprise architecture (EA) leaders pursue REST API strategies is because REST helps to expand ecosystems, grow market presence, and create new products, revenue streams and engagement channels.
REST APIs have become a shiny object. In our API strategy talks with clients, the goal is too often “implement REST APIs”. But the real business goals are to optimise experiences, operations, and collaboration with customers, partners and any other ecosystem player. REST APIs are just one technology for doing so.
The better strategy framing is digital bonding, which Forrester defines as any type of collaborative connection – enterprise-to-enterprise, person-to-person or enterprise-to-person – facilitated by one party’s software connecting to, communicating with, or leveraging the other party’s software. But REST-only strategies do not match the full range of business relationship dynamics.
The normal synchronous request-response mode of REST APIs is only one of the ways organisations connect their own applications, so why should that be the only way they connect with customers and partners? Answer: it shouldn’t be. EA professionals should lead their organisations beyond REST APIs.
Digital bonding beyond REST
Digital bonding includes both new and traditional mechanisms for connecting across enterprise boundaries. Predecessors to 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 two-way, 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 across a collection of related data schemas, allowing API users to navigate the data however they want.
Importantly, both are gaining support – albeit slowly – from API management solutions and API gateways. There is also growth in publishing events on protocols such as WebSockets and webhooks and on brokers such as Apache Kafka. Early examples of firms adding WebSockets to their digital bonding strategies include market data and messaging, whereas GraphQL has broader vertical usage.
For instance, 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. Then, whenever something happens related to that channel, Slack sends a message through the WebSockets connection. The developer decides which messages are interesting to act on.
Slack also provides its events API, which, instead of maintaining a long-running connection, sends selected event notifications one by one, such as when checking in new code kicks off a project build process.
Another example is how multiple providers serve market and cryptocurrency data via WebSockets. One such provider is Refinitiv with its market data platforms Enterprise Platform and Elektron Real Time in Cloud. Refinitiv supports WebSockets for both delivery and posting of market data.
For cryptocurrencies, developers connect to Kraken’s or Coinbase’s WebSocket feed, selecting specific channels for accessing different 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 further allows developers to see individual orders as they are 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 provides another way to achieve digital bonding. GraphQL can be used to serve up data access in application areas such as e-commerce, health, science and travel. Although GraphQL finds early public traction in a wider variety of verticals than WebSockets, many offerings are marked as experimental, beta, or otherwise under development.
They all provide flexible access to a dataset of some kind. For Deutsche Bahn and Helsinki Regional Transport Authority, it’s public transit data (eg, timetables, routes). For travel and entertainment, there’s TravelgateX, Universe and Yelp. There’s geodata (eg, GraphLoc, Countries List), health data (eg, Stanford University’s HIVdb), chemical reactions (eg, Catalysis Hub), development tools (eg, GitHub, GitLab), professional data (eg, Mattermark, LeanIX), and Holocaust archives (eg, EHRI).
Braintree goes beyond query-only data access to provide payment transactions via GraphQL, as do commercetools and Shopify for shopping carts and other e-commerce data.
WebSockets and GraphQL are only a start in going beyond REST. In addition to looking backward to traditional mechanisms, enterprise architects crafting enterprise digital bonding strategies can look to newer and emerging mechanisms, such as Web Components, eventing (eg, AsyncAPI, CloudEvents) and streaming. Some mechanisms might use new technologies or protocols, some might use old technologies in new ways (eg, application messaging, MQTT), and some might be patterns for using REST APIs.
But the point is to let the business problem – not tech religion – drive the style of digital bonding mechanism used.
Broadening the integration outlook
REST APIs are all the rage because there is a certain simplicity about them. But some business scenarios require different interaction models or richer semantics than REST can provide. If you are catching a stream of data updates or polling continuously to check if an event has happened, REST is cumbersome at best and can be expensive and harm scalability.
As an EA leader, you must remove any REST blinders you may have on. Open the aperture of innovation and possibilities by thinking, talking and designing in “virtual enterprise” terms – as if your organisation, your customers, your suppliers and other stakeholders were operating one process within one organisation.
Start with known problems and desired improvements to business outcomes – but don’t be restricted by those. Invent new problems, new potential outcomes, and even new business models. Ask how each party can add value and what triggers data, processes, events and transactions to flow across enterprise boundaries.
Refine the ideas and only then allow value analysis to sift through and prioritise possibilities.
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 is running on 11-12 October in London.
[ad_2]
Source link
