Forum Discussion

AndyTGardner's avatar
AndyTGardner
New Contributor
6 years ago

Defining Nested Data in Response Schema

I'm trying to define a schema for a response in the Yaml for my API and this includes a field being an array of sub data. My Yaml is as follows:

    PPOdata:
      type: object
      properties:
        PPO_Id:
          type: integer
          example: 256
        PPO_Name:
          type: string
          example: PPO_1
        PPO_Modules:
          type: array
          items:
            additionalProperties:
              type: object
              properties:
                ModuleName:
                  type: string
                  example: latency
                ModuleSettings:
                  type: string
                  example: Min 0, Max 10

So, as you can see above the the sub data field is called PPO_Modules and is an array of objects containing two fields. SwaggerHub shows this as valid and I'm able to save with no errors. With the examples, the example in the documentation shows as

{
  "PPO_Id": 256,
  "PPO_Name": "PPO_1",
  "PPO_Modules": [
    null
  ]
}

As the sub data is showing as Null, does this mean I have defined this incorrectly, even though SwaggerHub says it's valid, or have I defined this in a totally incorrect manner and misunderstood the use of additional properties to define the sub fields?

  • RonRatovsky's avatar
    RonRatovsky
    6 years ago

    You should add 'type: object' to the internal items array:

     

            items:
          type: object
          additionalProperties:
            type: object
            properties:
              ModuleName:
                type: string
                example: latency
              ModuleSettings:
                type: string
                example: Min 0, Max 10

    While the definition is valid, itt doesn't actually produce the result you'd expect. When you don't specify a type, it means that any type can be used (string, array, object, number...). The 'additionalProperties' will only take effect if the actual used value is an object, but in other cases it will be ignored. Having that definition does not implicitly set the type to be object.

  • RonRatovsky's avatar
    RonRatovsky
    Staff
    6 years ago

    You should add 'type: object' to the internal items array:

     

            items:
          type: object
          additionalProperties:
            type: object
            properties:
              ModuleName:
                type: string
                example: latency
              ModuleSettings:
                type: string
                example: Min 0, Max 10

    While the definition is valid, itt doesn't actually produce the result you'd expect. When you don't specify a type, it means that any type can be used (string, array, object, number...). The 'additionalProperties' will only take effect if the actual used value is an object, but in other cases it will be ignored. Having that definition does not implicitly set the type to be object.