Parameters:
arn:
Type:String
Description: Add comp arn as comma delimited string
Resources:
Type: AWS::ImageBuilder::ImageRecipe
Properties:
BlockDeviceMappings:
- InstanceBlockDeviceMapping
Components:
- ComponentArn:"arn"
- ComponentArn:"arn"
Description: String
Name: String
ParentImage: String
Tags:
Key : Value
Version: String
I am trying to pass the parameter values(arn) to the ComponentArn key here in the stack. The issue is I need to take the parameter values as comma seperated string. I am not getting how to split and add it here.
For that you use CommaDelimitedList parameter type.
Parameters:
arn:
Type: CommaDelimitedList
Description: Add comp arn as comma delimited string
Then you can reference individual elemnets in the list using Select
Related
Is it some how possible to specify constants/enums for properties inside referenced complex properties in OpenAPI?
I know for a simple string property I can specify some enum constants which I expect/ allow (as you can see in the example below at property sortOrder.
As you can see in this example I define the TestSearchModel with the property orderBy which is of a referenced type SortModel. SortModel is actually defined in another file of a framework (PS: I have access and the permission to change that framework for my needs). In this SortModel there is the property sortFieldName. I wish I could specify in TestSearchModel that I only allow e.g. ATTR_ONE. Is that possible?
Maybe you can image my use case. I would like to define a search operation which expects an input of type TestSearchModel. With this input it should be possible to define a column/property by with the sorting of the results found should be done.
openapi.yaml:
TestSearchModel:
type: object
properties:
orderBy:
$ref: "#/SortModel"
enum: // allowed values of property sortFieldName in SortModel
- ATTR_ONE
- ATTR_TWO
SortModel:
type: object
properties:
sortFieldName:
type: string
sortOrder:
type: string
enum:
- ASC
- DESC
This should be valid:
{
"orderBy": {
"sortFieldName": "ATTR_ONE",
"sortOrder": "ASC"
}
}
This should end up in an error, because 'ATTR_THREE' is not defined above in the allowed values:
"sortModel": {
"sortFieldName": "ATTR_THREE",
"sortOrder": "ASC"
}
I actually guess that with OpenAPI Spec this kind of specification is not possible. However may be you can provide some recommendations how to handle that.
I tried out the example above. OpenAPI generates the model classes without any error but (some kind of expected) without considering the limitation of the allowed strings for 'order by' property. I wish that an enum would be generated for ATTR_ONE and ATTR_TWO.
It's possible. You'll need to add an extra schema alongside the $ref that defines a property with the same name on the same nesting level.
If you use OpenAPI 3.0.x or 2.0, make sure to wrap the $ref into allOf:
TestSearchModel:
type: object
properties:
orderBy:
allOf:
- $ref: "#/SortModel" # or "#/components/schemas/SortModel" or whatever the correct $ref path is
- properties: # <---
sortFieldName: # <---
enum:
- ATTR_ONE
- ATTR_TWO
SortModel:
type: object
properties:
sortFieldName:
type: string
sortOrder:
type: string
enum:
- ASC
- DESC
In OpenAPI 3.1, you can add keywords directly alongside the $ref:
# openapi: 3.1.0
TestSearchModel:
type: object
properties:
orderBy:
$ref: "#/SortModel" # or "#/components/schemas/SortModel" or whatever the correct $ref path is
properties: # <---
sortFieldName: # <---
enum:
- ATTR_ONE
- ATTR_TWO
The problem with your schema above is that openapi won't read anything after the $ref field. So, the enum value you have placed there is ignored. You can move the enum to your SortModel and it will be available:
TestSearchModel:
type: object
properties:
orderBy:
$ref: "#/SortModel"
SortModel:
type: object
properties:
sortFieldName:
type: string
enum:
- ATTR_ONE
- ATTR_TWO
sortOrder:
type: string
enum:
- ASC
- DESC
If you are trying to reuse the enum, you can do this via a reference, like this
TestSearchModel:
type: object
properties:
orderBy:
$ref: "#/SortFields"
SortModel:
type: object
properties:
sortFieldName:
$ref: "#/SortFields"
sortOrder:
$ref: "#/SortOrderTypes"
SortOrderTypes:
type: string
enum:
- ASC
- DESC
SortFields:
type: string
enum:
- ATTR_ONE
- ATTR_TWO
In short, here's fragment of OpenAPI specification:
# Consider an imaginary Internet Service Provider that needs to limit
# one or multiple customers in different ways: bandwidth (inbound, outbound), media type (text / music / video), volume (total traffic volume, for example, 5 GB).
# per specific website (a user can have different limit for YouTube and Amazon).
# You'll likely want to rename some of the attributes but
#that's not the point (this API is fake and that's the best example I came up with to reproduce the issue).
components:
schemas:
ProviderLimit:
type: object
properties:
name:
type: string
website_id:
type: string
users:
type: array
items:
type: string
description: List of user IDs
minItems: 1
bandwidth:
type: object
$ref: '#/components/schemas/BandwidthLimit'
volume:
type: object
$ref: '#/components/schemas/VolumeLimit'
media:
type: string
enum:
- TEXT
- MUSIC
- VIDEO
BandwidthLimit:
properties:
incoming_speed:
type: string
format: int64
outcoming_speed:
type: string
format: int64
VolumeLimit:
properties:
target:
type: string
format: int64
The question is which approach shall I take:
Merge all the possible limits (bandwith, volume, media), make them all optional, and agree to specify just one of them on the client.
Use oneOf.
# Example of using oneOf
components:
schemas:
ProviderLimit:
type: object
properties:
name:
type: string
website_id:
type: string
users:
type: array
items:
type: string
description: List of user IDs
minItems: 1
limit_type:
type: object
oneOf:
- $ref: '#/components/schemas/BandwidthLimit'
- $ref: '#/components/schemas/VolumeLimit'
- $ref: '#/components/schemas/MediaLimit'
discriminator:
propertyName: type # or something else
It looks like option #2 looks a little bit better but overall one could tell #1 option is somewhat reasonable (it's very simple and doesn't overcomplicate the API). Is there a strong argument to use #2 besides it just looks a little bit better (for example, there's a use case where using #1 might not lead to expected results)?
In Azure API Management the CustomerId is specified as an integer with an integer example value:
openapi: 3.0.1
components:
schemas:
Customer:
type: object
properties:
CustomerId:
type: integer
format: int64
example: 100000
After saving, it changes to a string including a decimal separator:
example: '100000.0'
openapi: 3.0.1
components:
schemas:
Customer:
type: object
properties:
CustomerId:
type: integer
format: int64
example: '100000.0'
How can I specify integer example values?
After I write Sample(Json) like the screenshot below, it automatically generate the Payload, and I export this api, I got the yaml file like this, can it help you?
components:
schemas:
Customer:
type: object
properties:
CustomerId:
type: integer
I have an OpenAPI 3.0 schema where one of the properties (the taskRequireSkills array) needs to reference another schema (TaskRequireUserSkill), like this:
components:
schemas:
Task:
properties:
id:
type: integer
name:
type: string
taskRequireSkills:
type: array
schema: # ERROR : bad indentation of a mapping entry
$ref: '#/components/schemas/TaskRequireUserSkill'
created_at:
type: string
format: datetime
TaskRequireUserSkill:
properties:
id:
type: integer
skill_id:
type: integer
skill_name:
type: string
ordering:
type: integer
created_at:
type: string
format: datetime
But I get the "bad indentation of a mapping entry" error.
I suppose my syntax is invalid.
But which syntax is valid?
An array of $refs is defined as follows:
taskRequireSkills:
type: array
items:
$ref: '#/components/schemas/TaskRequireUserSkill'
I would like to post an array of strings like
[
"id1",
"id2"
]
to a Swagger based API. In my swagger file, I have those lines:
paths:
/some_url:
post:
parameters:
- name: ids
in: body
required: true
What is the correct way to specify the type of ids as an array of strings?
Update:
According to the specification, the following should work in my option:
parameters:
- in: body
description: xxx
required: true
schema:
type: array
items:
type: string
https://github.com/Yelp/swagger_spec_validator does not accept it and returns a long list of convoluted errors, which look like the code expects some $ref.
Your description of an array of string is correct, but the parameter definition misses the name property to be valid.
Here's a full working example:
swagger: "2.0"
info:
title: A dummy title
version: 1.0.0
paths:
/path:
post:
parameters:
- in: body
description: xxx
required: true
name: a name
schema:
type: array
items:
type: string
responses:
default:
description: OK
Try the online editor to check your OpenAPI (fka. Swagger) specs: http://editor.swagger.io/
I have created a swagger issue as the help provided by Arnaud, although is valid yaml, will give you NPE exceptions when trying to generate. You will need to provide an object like the following:
myDataItem:
type: object
description: A list of values
required:
- values
properties:
values:
type: array
items:
type: string
And then refer to it (in your post item etc):
schema:
$ref: "#/definitions/myDataItem"
For reference the github issue:
https://github.com/swagger-api/swagger-codegen/issues/6745
Note, the issue has been fixed in version 2.3.0 and higher, ideally you should upgrade to that version.
None of the answers worked for me. As it is stated in the following Baeldung article:
To better document the API and instruct the user, we can use the example label of how to insert values
So the full working example would be something like that:
swagger: "2.0"
info:
title: A dummy title
version: 1.0.0
paths:
/path:
post:
parameters:
- in: body
description: xxx
required: true
name: a name
schema:
type: array
items:
type: string
example: ["str1", "str2", "str3"]
responses:
default:
description: OK
You can check how the Example Value is now better informed in the Swagger editor.
For Array containing Object as it's content, definition for Object can be also expressed using definitions & $ref.
Example:
schema:
type: array
items:
$ref: '#/definitions/ObjectSchemaDefinition'
definitions:
ObjectSchemaDefinition:
type: string
The answer with the most votes got me in the right direction. I just needed an example of an array of objects where each one of them had a property which was an array of strings with more than one value in the strings array. Thanks to the documentation I got it working like this:
MyObject:
type: object
properties:
body:
type: array
items:
type: object
properties:
type:
type: string
values:
type: array
items:
type: string
example:
- type: "firstElement"
values: ["Active", "Inactive"]
- type: "SecondElement"
values: ["Active", "Inactive"]
One thing to keep in mind is that indentation is of paramount importance to swagger. If you don't indent things well, swagger will give you strange error messages.