Today’s modern systems have to talk to each other, exchange data and share services. Today, entire business models are based on the exchange of information via well-defined interfaces, also known as application programming interfaces (API). So, now that our world has been turned upside down by software, it’s time to use it as a foundation for further change and use APIs to embrace the next revolution: APIs are eating the world!
Let’s take Uber as an example. Uber’s core business is to bring together people who want to travel from A to B and drivers who want to provide this service. This is very similar to the taxi business, except that Uber has no taxis of its own and has not hired any drivers.
In the same way that Uber only accesses third parties who offer and consume the services, Uber also acts with regard to its corporate IT. Uber concentrates on developing the most important thing for them themselves (a mobile app with a high UX factor). For all other processes, Uber relies on external service providers and services. These are all connected to each other via an API.
For example, driver and passenger administration or payment services are not developed or operated by Uber directly. Only the APIs of the service providers are fed with Uber’s data. The implementation and management of the actual software is the responsibility of third parties. In this way, Uber is able to react much faster to market requirements and changes. Additionally, this also saves costs while gaining valuable market share.
APIs have changed the modern business world. For us mere “techies”, this evolution has created new challenges and requirements. First of all, if we want to get involved in the API business and develop or integrate it into our systems, it requires a higher level of understanding for our respective business domains. It is no longer enough just to be the expert for JPA or JSF and know which parameters to configure. APIs have a clear relevance to the domain and we need to understand this.
The technologies that APIs bring along are often not completely new technologies. We already know many concepts from the past and have already worked with them. Only the specifications change as to how we can and should use these technologies. For example, the serialization of data to transfer between two systems is nothing new. We have been doing this with XML for decades. In recent years, JSON has emerged as an alternative. Likely, we will deal with other formats such as Afro and others in the future. The topic of serialization as such remains, only the way in which we serialize the data changes.
SOAP as an API protocol is already ancient as far as tech is concerned. The same is true for the transmission via HTTP; even REST is nothing new in principle. And yet, APIs make it much more central to our thinking. At the same time new protocols spring into life. With GraphQL, for example, there has emerged a new type of data retrieval protocol, which concentrates on solving very special requirements.
With regards to security, there are new specifications for existing concepts and technologies. The authentication and authorization of access to and queries from different systems via APIs and tokens is nothing new. SAML is an XML-based standard was already standardized in the early 2000s. SAML is powerful, but focuses more on internal enterprise solutions. For communication across network boundaries and between heterogeneous systems, specifications such as OAuth and OpenID Connect have evolved from the changed requirements. However, they are also token-based.
Nevertheless, it is not only putting a new coat of paint on an old idea. A whole host of new technologies, new programming languages, and entire ecosystems continue to evolve, all focusing on solving problems with very specific requirements. We must not rest easily on our laurels.
New technologies, however small and insignificant they may initially appear, are now being created faster than ever before. Many of these disappear as quickly as they have come into existence, but one or two tools survive. And it is precisely these tools that can be used to solve future challenges. Familiarity with these tools can help us gain the necessary competitive edge in the business world.
We don’t have to be experts in every new technology when it comes out. But we should go through our world with open eyes and open minds.
To consume other APIs, we first need to get an overview of the different services on many different levels. APIs are partly a business process and partly a technical tool. Not all APIs work equally and on identical levels. We have to ask ourselves which APIs are relevant for our application.
In addition, we need to learn and understand that using third-party APIs means two things: a compromise and a dependency that may now have a stronger impact on our business processes than has been the case up to now. Having an advantage through the use of an API can mean that we have to deal with other disadvantages.
If we want to offer (public) APIs, we have to deal with two more new topics: API design and API management.
API design is mainly about creating an easy-to-learn and easy-to-use API that will be used by as many consumers as possible. In addition to its simplicity, it must also be difficult to use incorrectly. A company has pretty much one shot at this, because once an API is public and it is used, it can only be changed with great difficulty. An API must be extensible and thus ensure compatibility over several change cycles. And even if it is essentially the machines (or “systems”) that communicate via an API, the API is “read” by other developers. Topics such as documentation and naming (for objects, methods, attributes, etc.) suddenly become the focus of attention. It is not an easy task, but it bears a lot of responsibility.
But we are not only responsible for the design of the API at the beginning of its lifecycle. An API must be managed throughout its entire lifecycle and in several ways. These include topics such as security (access control, but also sealed test environments/sandboxes), performance, caching and last but not least, SLAs, which we as a provider can assure our consumers. What used to be just one aspect of our daily work now becomes the focus of our activities.
As API developers, we are responsible for the quality and usability of the API and thus the directly linked business success of the company. We no longer just manage an internal process in a small part of the company, we use our API to represent the company externally.
Hurry up! APIConference starts in: