Моделирование общей хэш-карты DTO в спецификации Swagger 2.0 - PullRequest
0 голосов
/ 10 мая 2019

Я использую swagger для генерации DTO в моем клиенте go, для существующих API REST. Тело запроса DTO имеет общую хэш-карту, такую ​​как:

class MyConfig {
   Map<String, Object> config;
}

Позволяет сказать, что в конфигурации 2 возможных ключа, значение - это отдельный объект для каждого ключа.

key1 = "_key1", and value1 = "type A"
key2 = "_key2", and value2 = "type B"

Я использовал расширение инспектора Swagger и сгенерировал спецификацию Swagger (OAS 2.0) для своего API. Сгенерированный файл yaml выглядит следующим образом:

MyConfig:
    properties:
      _key1:
        $ref: '#/definitions/_A'
      _key2:
        $ref: '#/definitions/_B'

В основном это соответствует классу типа MyConfig с 2 полями как «key1» и «key2». Я не думаю, что это сработает, если мой DTO на стороне сервера претерпит какие-либо изменения в будущем, например, поддержит другой ключ и значение на карте.

На самом деле это не соответствует моему фактическому вводу, который является hashmap.

Мне кажется, я должен смоделировать, как показано ниже:

MyConfig:
    properties:
      config:
        type: object
        additionalProperties:
           type: string
           $ref: {} -->(assuming {} represents a generic object)

Есть ли поддержка упоминания универсального объекта в спецификации swagger? Не уверен, какой подход на самом деле лучше / гибкий.

Спасибо!

...