I want to have different values for the annotation and the property name. Default root element used is the simple name of the data class. The value of the annotation is the same as the name of the property. Initialize your data class and use the mapper’s writeValueAsString () method to get the xml value. The generated data classes for the models have the JsonProperty annotation. Private val eventsRepository = mutableListOf()įun save(event: ShmonitoringEvent) = eventsRepository.add(event)įun find(filter: ShmonitoringEventFilter) = eventsRepository. Im generating an API client from Open API specs (3.0.0), using openapi-generator:5.4.0 and kotlin-spring generator. To save and find events we will have a simple service like this: While both models are quite simple, there are a few things that could be improved here. Here we make each field nullable, so that we can use any subset of those fields to find an event. To be able to find events, let's also introduce a filter model: According to the requirements mentioned above we might end up with something like this: Now, let's try to design an initial model. While moving forward, we'll also consider an option of building a client library, so the article will be covering both a REST API case and a library API case. It should also provide an API to find consumed events by host name, service name or owning team name.
The event itself should have information like: host name, service name, owning team name, status (Up, Down, Warning), uptime, number of processes and maybe some other stats. The service should provide an API to consume an event coming from the monitored system. Let's imagine we have to build a service at Wolt to store some monitoring data. Let’s have at some of the approaches we take at Wolt to build a good API with Kotlin and make our lives easier.
It is one of the few serialization frameworks that can invoke an. Thankfully, Kotlin provides a plenty of tools to design a great API. Jackson is a commonly used framework for serializing Java objects into JSON and vice versa.
#KOTLIN JACKSON ANNOTATIONS CODE#
Frustrated consumers, necessity for extra validations, delayed feedback and convoluted, hard to maintain code are just a few things you might have to pay with for poor design decisions during early development stages. Designing a type-safe, sane API that prevents consumers from misusing it could be crucial for further implementation of that API.
0 kommentar(er)
