I created a project that returns an array. Looking at the swagger.json everything looks fine, importing this swagger.json . But when I download the API definition from the developer portal I see some objects like ...Array, ...Array-1, ...Array-2. Which I don't expect:
How can I prevent this? How can I ensure that the generation behaves the same as my normal object (so no dashes, but dots). I created an example project that reproduces my issue: https://github.com/mvdiemen/SwaggerArrayGenerationExample.
Is this related to changes in Azure API management that are described over here? : https://blog.tomkerkhove.be/2018/04/13/changes-to-azure-api-management-openapi/
APIM does not support inlined schema. Try specifying schemas for response/request via $ref only, even if it's an array of object you've already defined - define a new object of type array and reference it.
So, instead of something like this:
"200": {
"description": "Success",
"schema": {
"uniqueItems": false,
"type": "array",
"items": {
"$ref": "#/definitions/SwaggerGenerationSample.Models.Response.Employee"
}
}
}
Have array itself defined in definitions and reference it:
"200": {
"description": "Success",
"schema": {
"$ref": "#/definitions/EmployeeArray"
}
}
...
"definitions": {
"EmployeeArray": {
"uniqueItems": false,
"type": "array",
"items": {
"$ref": "#/definitions/SwaggerGenerationSample.Models.Response.Employee"
}
}
}
Related
I am having a Azure logic app where I want to iterate over a dictionary as shown below.
"test": {"text1":"qabdstw1234",
"text2":"vhry46578"
},
Here, in my Logic app I am able to iterate over a list of dictionary but here I want to iterate over a dictionary.
Does anybody knows how to do it?
I have used parse JSON inorder to fetch test1 data from the JSON which you have provided and then used compose connector to get the same. Here is my Logic app :-
Here is the generated schema while using the sample JSON Payload which you have provided I'm using:-
{
"type": "object",
"properties": {
"title": {
"type": "string"
},
"text1": {
"type": "array",
"items": {
"type": "string"
}
},
"id": {
"type": "string"
},
"status": {
"type": "string"
}
}
}
Add a new action, search for Control and select the For each:
To process an array in your logic app, you can create a "Foreach" loop. This loop repeats one or more actions on each item in the array.
Source: Create loops that repeat workflow actions or process arrays in Azure Logic Apps
For a few weeks now, there is a new "Parameter" section in the Designer of Logic Apps. We can create parameters and use these parameters in the Logic Apps:
Unfortunately, there are two things that are missing (or not working yet):
We are not able to set the "current value" of a parameter (as shown below, the field Actual Value is grayed)
When we export the Logic App as an ARM template, parameters are not used in the ARM template as ARM parameters.
Am I missing something or is it just due to the fact that there are features not yet deployed?
I'm not either sure how default/actual values should work in the Logic App designer but for the export of the ARM template with the (designer) parameters I'm using the last build of LogicAppTemplateCreator and it works for me.
The template snippet contains "paramDateFrom" parameter with its default value and it is used in the parameters section of ARM:
...
"paramDateFrom": {
"type": "string",
"defaultValue": "2019-12-19"
}
},
"variables": {},
"resources": [
{
"type": "Microsoft.Logic/workflows",
"apiVersion": "2016-06-01",
"name": "[parameters('logicAppName')]",
"location": "[parameters('logicAppLocation')]",
"dependsOn": [],
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"DateFrom": {
"defaultValue": "[parameters('paramDateFrom')]",
"type": "String"
}
},
...
The template parameters file contains the actual value:
...
"parameters": {
"paramDateFrom": {
"value": "2019-12-20"
}
I'm trying to get into JSON schema definitions and wanted to find out, how to achieve a deeper object uniqueness in the schema definition. Please look at the following example definition, in this case a simple IO of a module.
{
"$schema": "http://json-schema.org/draft-06/schema#",
"type": "object",
"required": ["modulIOs"],
"properties": {
"modulIOs": {
"type": "array",
"uniqueItems": true,
"items": {
"allOf": [
{
"type": "object",
"required": ["ioPosition","ioType","ioFunction"],
"additionalProperties": false,
"properties": {
"ioPosition": {
"type": "integer"
},
"ioType": {
"type":"string",
"enum": ["in","out"]
},
"ioFunction": {
"type":"string"
}
}
}
]
}
}
}
}
When I validate the following with i.E. draft-06 I get a positive validation.
{"modulIOs":
[
{
"ioPosition":1,
"ioType":"in",
"ioFunction":"240 V AC in"
},
{
"ioPosition":1,
"ioType":"in",
"ioFunction":"24 V DC in"
}
]
}
I'm aware that the validation is successfull because the validator does what he's intended to - it checks the structure of a JSON-object, but is there a possibility to validate object value data in deeper objects or do i need to perform the check elsewhere?
This is not currently possible with JSON Schema (at draft-7).
There is an issue raised on the official spec repo github for this: https://github.com/json-schema-org/json-schema-spec/issues/538
If you (or anyone reading this) really wants this, please thumbsup the first issue comment.
It's currently unlikely to make it into the next draft, and even if it did, time to impleemntations picking it up may be slow.
You'll need to do this validation after your JSON Schema validation process.
You can validate data value of your object fields by using JSON schema validation.
For example, if you need to check if ioPosition is between 0 and 100 you can use:
"ioPosition": {
"type": "integer",
"minimum": 0,
"maximum": 100
}
If you need to validate ioFunction field you can use regualr expression such as:
"ioFunction": {
"type": "string",
"pattern": "^[0-9]+ V [A,D]C"
}
Take a look at json-schema-validation.
I'm writing a simple JSON schema and using minItems to validate the number of items in a given array. My schema is as follows:
{
"title": "My Schema",
"type": "object",
"properties": {
"root": {
"type": "array",
"properties": {
"id": {
"type": "string"
},
"myarray": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 4,
"uniqueItems": true
},
"boolean": {
"type": "boolean"
}
},
"required": ["id","myarray","boolean"]
}
},
"required": [
"root"
],
"additionalProperties": false
}
Now I would expect the following JSON to fail validation given the element myarray has nothing in it. But when using this online validator, it passes. Have I done something wrong or is the schema validator I'm using faulty?
{
"root":[
{
"id":"1234567890",
"myarray":[],
"boolean":true
}
]
}
I am not sure why or what it is called, but the correct schema definition for your requirement should be as shown further down.
From what I understand from the JSON Schema definitions, you should declare the properties of an array inside the items declaration. In your schema you where defining properties outside of the array item declaration.
In your schema you have the two different types of array declaration:
Once with just a single object (a string for the "myarray" object)
Once with a complex object (the object name "myComplexType" in the code below)
Have a look at the definitions of both, how they are structured and how they would be interpreted.
The corrected schema:
{
"title": "My Schema",
"type": "object",
"properties": {
"root": {
"type": "array",
"items": { <-- Difference here - "items" instead of "properties"
"type": "object", <-- here - define the array items as a complex object
"title": "myComplexType", <-- here - named for easier referencing
"properties": { <-- and here - now we can define the actual properties of the object
"id": {
"type": "string"
},
"myarray": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 4,
"uniqueItems": true
},
"boolean": {
"type": "boolean"
}
}
},
"required": [
"id",
"myarray",
"boolean"
]
}
},
"required": [
"root"
],
"additionalProperties": false
}
Remove the comments I added with <-- when copying over to your code, added for pointing where there changes are.
As a note, I do however don't understand why the validator didn't give an error for the 'malformed' schema, but might just be that it saw the definition as you had it as additional properties, not entirely sure.
The only thing wrong with your schema is that the root property should have type object instead of array. Because the properties keyword is not defined for arrays, it is ignored. Therefore, the part of the schema you were trying to test was completely ignored even though it was correct.
Here is the relevant passage from the specification
Some validation keywords only apply to one or more primitive types. When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed.
http://json-schema.org/latest/json-schema-validation.html#rfc.section.4.1
Some Facebook graph api endpoints return arrays like this:
"likes": {
"data": [
{
"id": "000000",
"name": "Somebody"
}
],
"paging": {
"cursors": {
"after": ".....",
"before": "....."
}
}
}
While others return arrays like this:
"actions": [
{
"name": "Comment",
"link": "https://www.facebook.com/000000/posts/00000"
},
{
"name": "Like",
"link": "https://www.facebook.com/00000/posts/00000"
}
]
Does anyone know of where in the documentation Facebook explains when an array is going to be returned wrapped in a { data: [...] } object? As far as I know, facebook just lists everything that is an array as array and doesn't explain when a data object will be returned.
I guess I can assume that if something can be "paged" that it will be in a data structure...
Am I missing some documentation about Facebook data types somewhere?
You are right, they seem to list everything that is an array as array.
For instance, in the documentation for the Post Endpoint, the return type for both "likes" and "actions" is listed as an array.
Likes
...
Array of objects containing the id and name fields.
Requesting with summary=1 will also return a summary object
containing the total_count of likes.
Actions
...
Array of objects containing the name and link
I think that's why you have to query the actual end point, and inspect the JSON (like you are doing) and figure out what is actually coming back.
No wonder the Facebook API is the proud winner of the "Worst API" Award!
Any feed(feeds/posts)(that is every array) you retrieve will be retured in data object, inside this data object the array will be there.Also the friend list is embedded in data object,which will have array of objects. Something like this:
{"data": [
{
"id": "..",
"name": ".."
}
],
"paging": {
"cursors": {
"after": ".....",
"before": "....."
}
}
}
While in all other api requests , which do not return an array, have structure like this:
{
"id": "..",
"name": ".."
}