Синхронизация конфигурации OpenAPI и JSON -B с помощью Quarkus - PullRequest
Новая
       27

Синхронизация конфигурации OpenAPI и JSON -B с помощью Quarkus

1 голос
/ 23 апреля 2020

Пока что

Я пытаюсь запустить службу REST, следуя официальному руководству , используя RESTEasy и JSON -B. Я также добавил поддержку OpenAPI для тестирования службы, следуя этому руководству .

Обе части работают самостоятельно, служба правильно возвращает жестко закодированные демонстрационные данные. Пользовательский интерфейс Swagger показывает доступные маршруты и позволяет их вызывать.

Однако, это не так гладко, как мне бы хотелось ...

Играя, я создал маршрут, возвращающий объект содержащий Instant. Во время вызова я представляю строку в формате ISO 8601 для свойства, как я и ожидал.

Однако для этого свойства связана схема 

Instant:
  type: object
  properties:
    nanos:
      format: int32
      type: integer
    seconds:
      format: int64
      type: integer
    epochSecond:
      format: int64
      type: integer
    nano:
      format: int32
      type: integer

, которая не соответствует тому, что на самом деле возвращается. Я как бы понимаю, откуда это. Очевидно, quarkus-smallrye-openapi использует другую настройку при проверке Instant из того, что использует quarkus-resteasy-jsonb.

Для последнего я уже понял, что для манипулирования пользовательским можно использовать пользовательский JsonbAdapter. форматирования. Например: 

public class JsonbInstantTypeAdapter implements JsonbAdapter<Instant, OffsetDateTime> {
    @Override
    public OffsetDateTime adaptToJson(Instant obj) {
        return OffsetDateTime.ofInstant(obj, ZoneId.systemDefault());
    }

    @Override
    public Instant adaptFromJson(OffsetDateTime obj) {
        return obj.toInstant();
    }
}

public class TestTimestamps {
    @JsonbTypeAdapter(JsonbInstantTypeAdapter.class)
    public Instant getDueTime() {
        return Instant.now();
    }
}

Это приводит к сериализации Instant после преобразования в часовой пояс системы, что может быть проще для чтения во время отладки.

Я мог понять только частично как настроить схему. Аннотирование метода следующим образом: 

public class TestTimestamps {
    @Schema(type = SchemaType.STRING, format = "date-time")
    public Instant getDueTime() {
        return Instant.now();
    }
}

приводит к созданию правильного примера значения, но сгенерированная схема все еще знает, что это мгновение, поэтому она генерируется как 

dueTime:
    allOf:
        - $ref: '#/components/schemas/Instant'
        - format: date-time
          type: string

В идеале, я В любом случае не хотелось бы аннотировать каждый метод отдельно.

Вопрос

Есть ли способ настроить для всего проекта на использование определенного адаптера для данного типа? И есть ли способ убедиться, что сгенерированная схема OpenAPI фактически представляет этот адаптированный тип вместо исходного?

1 Ответ

0 голосов
/ 24 апреля 2020

Спецификация MicroProfile позволяет переопределить схему для указанного c класса

. Добавление этого в ваш Quarkus application.properties переопределит схему Date 

mp.openapi.schema.java.util.Date = { \
  "name": "EpochMillis" \
  "type": "number", \
  "format": "int64", \
  "description": "Milliseconds since January 1, 1970, 00:00:00 GMT" \
}

Это будет работать для ваша проблема с Instant. См. https://github.com/eclipse/microprofile-open-api/blob/master/spec/src/main/asciidoc/microprofile-openapi-spec.adoc#core -конфигурации

...