Apache Camel OpenAPI Contract-First Example in SpringBoot

Posted by on December 3, 2024 No comments

Contract-First means what the name implies that we write the contract between client and server first and implement the code for it after. This is a good way to break up the task of creating an API in smaller parts which can be handled over multiple professions. For example, the OpenAPI specification can be created by an IT-architect and the implementation can be done by a programmer, and lastly the API documentation can be carried out by an communications expert.

In this article I’m going to build a simple OpenAPI implementation in Apache Camel and it’s rest-openapi component in a SpringBoot application.

1. We start with the API Specification:

openapi: 3.0.3
info:
  title: Basic API
  version: "1.0"
paths:
  /test:
    get:
      operationId: test
      responses:
        200:
          description: Default response
  /user/{userId}:
    get:
      operationId: getUser
      parameters:
        - name: userId
          in: path
          required: true
          schema:
            type: string
      responses:
        200:
          description: Default response

A few things to note here:
/test – this is the url that the client will use
operationId for the test endpoint – is the route that will receive the call from url above
/user/{userId} – url with parameter that the client will use
operationId – here the operationId does not match the url, which is fine. The call will go to the route direct:getUser with the userId in a header on the message seen below

2. Implementation of the Camel solution

package com.example.contract_first_example;


import org.apache.camel.builder.RouteBuilder;
import org.springframework.stereotype.Component;


/**
 * A Camel Java DSL Router for Contract First Example
 */
@Component
public class MyApp extends RouteBuilder {
    @Override
    public void configure() throws Exception {
        rest().openApi().specification("hello-rest-service.yaml");

        from("direct://hello")
            .setBody().constant("Hello from Camel!");

        from("direct://getUser")
            .process(exchange -> {
                exchange.getMessage().setBody("Hello from user: " 
                             + exchange.getMessage().getHeader("userId"));
            });
    }
}

3. Now the implementation is done and we move on to testing:

PS C:\Users\niklas> curl -XGET localhost:8080/hello
Hello from Camel!
PS C:\Users\niklas> curl -XGET localhost:8080/user/11
Hello from user: 11

And that is all there is – pretty simple, like most things in the Camel world 😉

Tested on Java 17, OpenAPI 3.0, Apache Camel 4.9.0 and SpringBoot 3.3.4 in a Windows 10 environment

Example of the Builder Pattern in Java

Posted by on August 5, 2024 No comments

A small example of the Builder Pattern in Java. We are going to build cars with different colors, brands and models 🙂

Car.java

public class Car {
    private String brand;
    private String color;
    private String model;

    public String getBrand() {
        return brand;
    }
    public void setBrand(String brand) {
        this.brand = brand;
    }
    public String getColor() {
        return color;
    }
    public void setColor(String color) {
        this.color = color;
    }
    public String getModel() {
        return model;
    }
    public void setModel(String model) {
        this.model = model;
    }
}

CarBuilder.java

public class CarBuilder {
    private Car car;
    
    private CarBuilder() {
        car = new Car();
    }
    public static CarBuilder aCar() {
        return new CarBuilder();
    }
    public CarBuilder withBrand(String brand) {
        car.setBrand(brand);
        return this;
    }
    public CarBuilder withColor(String color) {
        car.setColor(color);
        return this;
    }
    public CarBuilder withModel(String model) {
        car.setModel(model);
        return this;
    }
    public Car build() {
        return car;
    }
}

With these two classes above we can now build some cars:
Main.java

public class Main {
    public static void main(String[] args) {
        Car myFirstCar = CarBuilder.aCar().withBrand("Volvo")
                                          .withColor("Blue")
                                          .withModel("XC90")
                                          .build();

        Car mySecondCar = CarBuilder.aCar().withBrand("Skoda")
                                           .withColor("Grey")
                                           .withModel("130L")
                                           .build();
        System.out.println("My first car was a " + myFristCar.getBrand());
        System.out.println("My second car was a " + mySecondCar.getBrand());
    }
}

Should print:

My first car was a Volvo
My Second car was a Skoda

Tested on Ubuntu 20.04.4 LTS and Java 21

Kubernetes: Reference a section or value inside a manifest

Posted by on June 12, 2024 No comments

A colleague showed me this neat trick so I didn’t have to write the same information twice in a Ingress manifest file. I needed to map two hosts to the same path, and instead of duplicate the same information twice we can just reference the “http” section in the previous definition in the second host.

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: default
  annotations:
spec:
  ingressClassName: nginx
  rules:
    - host: my-first.domain.se
      http: &http-paths
        paths:
          - path: /my-application
            pathType: Prefix
            backend:
              service:
                name: my-application-service
                port:
                  number: 8080
    - host: my-second.domain.se
      http: *http-paths

The trick here is to use the &-sign to mark a place in manifest that you want to reference. In this example I named the reference “&http-paths”. When we later define the second host (my-second.domain.se) we can just de-reference the reference with the *-sign, here show as “*http-paths”. This will “copy” the whole http section with path, service and port, from the first definition and “paste” it into the second host section.
In Kubernetes this will be de-referenced and look like I put the same information in both hosts

Tested on Tanzu Kubernetes v1.22