So far, I've focused on the API design phase in posts and articles published. But a well elaborated API design is only one building block for a balanced API experience in terms of API consumers. Architecture topics represent another important building block. In the API community, the term "API architecture" pops up time and again. But what exactly is meant by it?
API architecture?
For many, "API architecture" is probably just another word creation. This neologism is gaining importance as system architectures become more and more complex. In the context of APIs, we are moving in the context of evolutionary architectures. When did software and system architectures become evolutionary and what exactly does this mean? Evolutionary architectures should and may develop over time. They are a concept that was thought up by Rebecca Parsons and Neal Ford [Building Evolutionary Architectures, O'Reilly 2018]. Architectures around APIs fit right into this concept, as the ultimate goal is, after all, to design and develop APIs in such a way that proper changes can be made for ease of use without causing breaks in use, known as breaking changes, on the part of consumers. To accomplish this, we now need an abstraction layer. This is important so that we don't get lost in technologies on both the provider and consumer side. An adequate aid here is patterns with which any kind of architecture can be abstracted.
Use of patterns
In the context of APIs, the following three kinds of patterns are interesting for us; Facade / Adapter, Strangler Fig and the API Layer Model. I will now describe these in more detail below and classify them in terms of usefulness.
Facade / Adapter
These two patterns are basically mentioned first in the context of a migration to a new service structure, mostly in the form of microservices, and are very similar, even though a Facade is less complex compared to an Adapter. The latter presupposes the respective architecture around a so-called component, which could carry out a protocol conversion, for example. The history of both goes back to the Gang of Four and the patterns were revived in Richardson's Microservice Pattern in the form of the Gateway Pattern.
Strangler Fig
The Strangler Fig pattern is basically a kind of a facade that, roughly speaking, intercepts the API requests and continues to shield the respective query complexity for consumers. In terms of evolutionary architectures, this means that the Strangler Fig Pattern supports an existing system to change. This is achieved by adding a new component while something existing is still present and in use. The goal is now to gradually move to a new approach, but without a consumer of the service or API noticing a change in the backend.
API Layer Pattern
If we now look at it more from an enterprise context, we are confronted with an API Layer Pattern. Unfortunately, this was and still is a general practice from which vendors of solutions in the integration context do not shy away either. The idea behind the pattern is actually quite simple, as all communication should go through the respective layers. But these layers can create a high level of coupling, which can then lead to duplicates again in order to bypass the call of a specific layer. Thus, a high complexity can also go along with it.
In view of evolutionary systems, it remains to be stated that the use of the API Layer Pattern in comparison to Strangler Fig does not contribute necessarily to the development speed and security of such a system.
API management solutions as a must-have tool?
Even if one does not exactly think and plan in evolutionary architectures now, many still try to find their salvation in API management solutions. According to vendors, this is a must-have for anyone who wants to develop and deploy APIs. But the introduction of an API management solution, an API gateway or even a service mesh only makes really sense if the first API services have already been developed and the respective teams understand that the aforementioned components help them to develop further with APIs into the evolutionary architectures already mentioned. After all, API management solutions are not an end in themselves, but rather support existing processes. This is exactly where we come full circle with topics pertaining to API Operations (APIOps).
Conclusion
When we think about APIs and architectures, we need to pause for a moment and ask ourselves what specifically we actually want to achieve with APIs that have been created or are yet to be created. Only then can we make initial decisions regarding a possible architecture. In the end, it must be clear that this architecture does not necessarily have a long life and we therefore need a high degree of flexibility, which providers of a large ready-made solution cannot necessarily guarantee.
Was this post helpful?
More articles
fromDaniel Kocot
16.4.2024 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Daniel Kocot
Senior Solution Architect / Head of API Consulting
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.