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
Serverless workflows have gained renewed interest and usefulness with the rise of serverless architectures. Once seen as centralized and monolithic, they now play a key role in cloud-based event and service orchestration. Until recently, there was no vendor-neutral way to describe service orchestration, so developers were dependent on vendors and vendor implementations. We realized that we needed a common, standards-based language for describing serverless workflows.
Continue reading Orchestrate event-driven, distributed services with Serverless Workflow and Kubernetes
With the release of Apache Camel K, it is possible to create and deploy integrations with existing applications that are quicker and more lightweight than ever. In many cases, calling an existing REST endpoint is the best way to connect a new system to an existing one. Take the example of a cafe serving coffee. What happens when the cafe wants to allow customers to use a delivery service like GrubHub? You would only need to introduce a single Camel K integration to connect the cafe and GrubHub systems.
In this article, I will show you how to create a Camel K integration that calls an existing REST service and uses its existing data format. For the data format, I have a Maven project configured with Java objects. Ideally, you would have this packaged and available in a Nexus repository. For the purpose of my demonstration, I utilized JitPack, which lets me have my dependency available in a repository directly from my GitHub code. See the GitHub repository associated with this demo for the data format code and directions for getting it into JitPack.
Continue reading “Call an existing REST service with Apache Camel K”
In this article, we’ll look at using OpenAPI with .NET Core. OpenAPI is a specification for describing RESTful APIs. First, I’ll show you how to use OpenAPI to describe the APIs provided by an ASP.NET Core service. Then, we’ll use the API description to generate a strongly-typed client to use the web service with C#.
Writing OpenAPI descriptions
Developers use the OpenAPI specification to describe RESTful APIs. We can then use OpenAPI descriptions to generate a strongly-typed client library that is capable of accessing the APIs.
Note: Swagger is sometimes used synonymously with OpenAPI. It refers to a widely used toolset for working with the OpenAPI specification.
Continue reading “Using OpenAPI with .NET Core”
Red Hat recently released the first Red Hat JBoss Enterprise Application Platform expansion pack (JBoss EAP XP) version 1.0. This version enables JBoss EAP developers to build Java microservices using Eclipse MicroProfile 3.3 APIs while continuing to also support Jakarta EE 8. This article goes into detail on the nature of this new offering and an easy way to get started.
Continue reading Red Hat JBoss Enterprise Application Platform expansion pack 1.0 released
Many front-end developers are discovering the benefits of contract-first development. With this approach, front- and back-end developers use OpenAPI to collaboratively design an API specification. Once the initial specification is done, front-end developers can use API definitions and sample data to develop discrete user interface (UI) components. Defining a single OpenAPI spec improves cross-team collaboration, and API definitions empower front-end developers to design our initial workflows without relying on the back end.
Continue reading Contract-first development: Create a mock back end for realistic data interactions with React
API-first design is a commonly used approach where you define the interfaces for your application before providing an actual implementation. This approach gives you a lot of benefits. For example, you can test whether your API has the right structure before investing a lot of time implementing it, and you can share your ideas with other teams early to get valuable feedback. Later in the process, delays in the back-end development will not affect front-end developers dependent on your service so much, because it’s easy to create mock implementations of a service from the API definition.
Much has been written about the benefits of API-first design, so this article will instead focus on how to efficiently take an OpenAPI definition and bring it into code with Red Hat Fuse.
Continue reading “API-first design with OpenAPI and Red Hat Fuse”
Nowadays technology companies are adopting the API as one of the most valuable pieces of their business.
What does it mean when we talk about API-first development? We already know the benefits of using an API-first approach:
- Reduced interdependencies
- Earlier validation
- Early feedback with the freedom to change
- Improved efficiency
This article describes what it means to use the API-first design approach. It also walks through an example of using this approach with the OpenAPI Specification and with oas-tools as the Node.js back-end application, which enables you to care only about the business logic. All the validation of incoming requests are done by the
oas-tools library (based on the OpenAPI Specification file provided).
Continue reading “Building a Node.js service using the API-first approach”
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”
Launched nearly two years ago, the Eclipse MicroProfile project is moving fast with four releases and eight subspecs having at least two implementations each. Because it’s a fast moving target, this post tries to give an overview of MicroProfile 1.3, which was released on September 30th, and helps you to get started with the specification.
Continue reading “MicroProfile Status in Version 1.3”