OpenAPI

Red Hat JBoss Enterprise Application Platform expansion pack 1.0 released

Red Hat JBoss Enterprise Application Platform expansion pack 1.0 released

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

Share
Contract-first development: Create a mock back end for realistic data interactions with React

Contract-first development: Create a mock back end for realistic data interactions with React

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

Share
API-first design with OpenAPI and Red Hat Fuse

API-first design with OpenAPI and Red Hat Fuse

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”

Share
Building a Node.js service using the API-first approach

Building a Node.js service using the API-first approach

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”

Share
Contract-First API Design with Apicurio and Red Hat Fuse/Camel

Contract-First API Design with Apicurio and Red Hat Fuse/Camel

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”

Share