As a developer, I'm always excited to attend so many great sessions addressing critical challenges in the Apache Kafka ecosystem. One example is how changes to event-driven APIs are leading developers to focus on contract-first development for Kafka.
This article discusses the journey Kafka users have taken to get on the API bandwagon and how developers are using contracts to describe brokers without losing control of their data in the cluster. A critical component for effective schema governance is having a schema registry such as Apicurio Registry.
Contract-First Development — the Event-Driven Way!
Introduction
Contract first application development is not limited to synchronized RESTFul API calls. With the adoption of event-driven architecture, more developers are demanding a way to set up contracts between these asynchronous event publishers and consumers. Sharing what data format that each subscriber is consuming, what data format is used from the event publisher, in a way OpenAPI standards is going to be very helpful.
But in the asynchronous world, it is ever more complex, not only do you need to be caring about the data schema, there are different protocols, serializing, deserializing mechanisms, and various support libraries. In fact, there are talks on AsyncAPI. But I am going to show you that what can be done today, is to use ONE of the most commonly used solutions in building EDA, “Kafka”. And show how to do Contract First Application Development using Camel + Apicurio Registry.
Designing REST API — What Is Contract First?
When designing a great REST API, it's important to have great microservices. Contract First approach helps you in designing a great contract before implementing it. However, it does not come easy!
You might also like: Contract-First API Design With Apicurio and Red Hat Fuse/Camel
You Will Learn
- What is Contract First approach of designing REST API?
- What are advantages of Contract First approach?
- What are disadvantages of Contract First approach?
- When do you adopt Contract First approach?
REST API
This is the third article in a series of articles on REST APIs: