Most of the new cloud-native applications and microservices designs are based on event-driven architecture (EDA), responding to real-time information by sending and receiving information about individual events. This kind of architecture relies on asynchronous, non-blocking communication between event producers and consumers through an event streaming backbone such as Red Hat AMQ Streams running on top of Red Hat OpenShift. In scenarios where many different events are being managed, defining a governance model where each event is defined as an API is critical. That way, producers and consumers can produce and consume checked and validated events. We can use a service registry as a datastore for events defined as APIs.
From my field experience working with many clients, I’ve found the most typical architecture consists of the following components:
In this article, you will learn how to easily integrate your Spring Boot applications with Red Hat Integration Service Registry, which is based on the open source Apicurio Registry.
Continue reading “Integrating Spring Boot with Red Hat Integration Service Registry”
This article introduces new storage installation options and features in the Red Hat Integration service registry. The service registry component is based on Apicurio. You can use it to store and retrieve service artifacts such as OpenAPI specifications and AsyncAPI definitions, and for schemas such as Apache Avro, JSON, and Google Protobuf. We’ve provided Red Hat Integration’s Service Registry 1.1 component as a general availability (GA) release in Red Hat Integration 2020-Q4.
Continue reading New features and storage options in Red Hat Integration Service Registry 1.1 GA
Last year, the Apicurio developer community launched the new Apicurio Registry project, which is an API and schema registry for microservices. You can use the Apicurio Registry to store and retrieve service artifacts such as OpenAPI specifications and AsyncAPI definitions, as well as schemas such as Apache Avro, JSON, and Google Protocol Buffers.
Because the registry also works as a catalog where you can navigate through artifacts, adding a new web-based user interface (UI) was a priority for the current Apicurio Registry 1.2.2 release. With this release, the Apicurio community has made the Apicurio Registry available as a binary download or from container images. To make it easier to set up and manage your Apicurio Registry deployment, they have also created a new Kubernetes Operator for the Apicurio Registry.
This article is a quick introduction to the new Apicurio Registry UI and Apicurio Registry Operator. I’ll show you how to access these new features in Apicurio 1.2.2 and describe a few highlights of using them. For a more detailed demonstration, check out my video tutorial introducing the new UI and Kubernetes Operator.
Continue reading “First look at the new Apicurio Registry UI and Operator”
APIs are the cornerstone of so many recent breakthroughs: from mobile applications, to the Internet of Things, to cloud computing. All those technologies expose, consume, and are built on APIs. And those APIs are a key driver for generating new revenue. Salesforce generates 50% of its revenue through APIs, Expedia generates 90% of its, and eBay generates 60% of its. With APIs becoming so central, it becomes essential to deal with full API lifecycle management. The success of your digital transformation project depends on it!
This article describes a set of full API lifecycle management activities that can guide you from an idea to the realization, from the inception of an API program up to management at scale throughout your whole company.
Continue reading “Full API lifecycle management: A primer”
This is part one of my two-article series that demonstrates how to implement contract-first API design using Apicurio and Red Hat Fuse. It covers how to create an OpenAPI standard document as the contract between API providers and consumers using Apicurio Studio. It also shows how to quickly create mock tests using Red Hat Fuse which is based on Camel.
There are two common approaches when it comes to creating APIs:
- Code first (top-down)
- Contract first (bottom-up)
Continue reading “Contract-First API Design with Apicurio and Red Hat Fuse/Camel”