I am trying to write a schema for my JSON file, one of filed shoud be either one of true or false or null
Is there any type which I can use to address above? I am using below types but it seems it doesn't work my schema evaluator
"my_column":
type :{
enum:["true","false","null"]
}
Can someone gives me any hint?
Related
I am trying to document with OpenAPI a query string which look like
filtered[0][id]=code&filtered[0][value]=12345
and contains a list of object with properties id and value.
My yaml documentation looks like the following
parameters:
- name: filtered
in: query
description: filters to be applied
explode: true
style: deepObject
schema:
type: array
items:
properties:
id:
description: name of the field to be filtered
type: string
value:
description: value of the filter
type: object
The problem is the following: it looks like the style: deepObject option works only for one level, and not at the second level where my objects actually are. That is, it expects a query string like
?sorted[0]=%7B%0A%20%20%22id%22%3A%20%22string%22%2C%0A%20%20%22value%22%3A%20true%0A%7D
with the object not serialized as an array with id and value keys.
Is there a way to solve this?
This is not possible as of OpenAPI 3.1
OpenAPI 3.0/3.1 Specifications currently defines the deepObject behavior only for simple objects (with primitive properties) such as
{
"id": 5,
"name": "Bob"
}
but not for arrays and not for nested objects.
Since the behavior for arrays and nested objects is not defined, there's really no way to describe your query string. Technically, the only way would be to define filtered[0][id], filtered[0][value], etc. as individual query parameters.
If you are designing a new API (rather than describing an existing one), consider passing the array of objects in the request body instead.
As name implies, :), deepObject style only "provides a simple way of rendering nested objects", not arrays. At the least according to Version 3.0.1 it applies only to objects.
Note that even nested objects might be not yet supported by tools because the specification "does not provide such examples".
So your format is not compatible with Open API, yet may be you can define you query as parameters which follow a regex. I such cases usually I do my best yet provide some explanation
https://swagger.io/specification/
Update. Apparently, after somebody demanded a 'descriptive error' message for nested objects, a patch (PR) to support nested objects was suggested at https://github.com/swagger-api/swagger-js/pull/1450 . Regretfully it was decided not to incorporate this feature, and PR 1450 was rejected.
I know it's an old question, but starting open api 3 there is a support for what you looking for
https://swagger.io/docs/specification/describing-parameters/#schema-vs-content.
it was reported as a bug that was fixed with openapi generator 6.0.1 +
https://github.com/OpenAPITools/openapi-generator/issues/4808
parameters:
- in: query
name: filter
content:
application/json:
schema:
schema:
$ref: "#/components/schemas/Filter"
While developing a client application using one of our existing REST services, I have the choice for using JSON or XML responses. The XML responses are described by XSD files with schema information.
With these XML Schemas I can determine what datatype a certain result must be, and the client can use that information when presenting the data to the user, or when the client asks the user to change a property. (How is quit another question btw as I cannot find any multiplatform Delphi implementation of XML that supports XSD schemas... but like i said: that's another question).
The alternative is to use a JSON response type, but then the client cannot determine the specific datatype of a property because everything is send as a string.
How would a client know that one of those properties is a index from an enumerated type, or a integer number, or an amount or a reference to another object by its ID maybe? (These are just examples)
I would think that the client should not contain "hardcoded" info on the structure of the response, or am I wrong in assuming that?
JSON doesn't have a rich type system like XML does, and JSON doesn't have a schema system for describing things like enumerations and references like XML does. But JSON has only a few data types, and the general formatting of the JSON is self-describing in terms of what data type any given value is using (see the official JSON spec for more details):
a string is always wrapped in quotation marks:
"fieldname": "fieldvalue"
a numeric value is digit characters without quotations:
"fieldname": 12345
an object is always wrapped in curly braces:
"fieldname": { ... object data ... }
an array is always wrapped in square braces:
"fieldname": [ ... array data ... ]
a boolean is always a fixed true or false without quotations:
"name": true
"name": false
a null is always a fixed null without quotations:
"name": null
Anything beyond that will require the client to have external knowledge of the data that is being sent (like a schema in XML, since XML itself does not describe data types at all).
For a sample JSON data which looks like this -
{
"children":{
"Alice":{...},
"Jamie":{...},
"Bob":{...}
// Any new child with a given unique name will be added to this object
},
childrenOrder:["Alice", "Bob", "Jamie"]
}
In the corresponding JSON Schema, I am trying to limit the valid values in "childrenOrder" array to be from the run time children keys.
I didn't see any means of referring to runtime dynamic values in the official JSON Schema documentation (http://json-schema.org/documentation.html).
Is this even possible at the moment?
For the sake of brevity I omitted JSON Schema code. I can add it if folks think it is needed to address the question.
Thanks in advance.
No it is not possible using the current JSON Schema specification. However, there is a proposal for the next version of JSON Schema that could change that.
https://github.com/json-schema/json-schema/wiki/%24data-(v5-proposal)
I'm tring my hand in Meteor - so far, I like it :-)
However, I am trying to store a JSON object directly into miniMongo, but not getting anywhere - while I thought that was the purpose :-)
testVar = {"test":"this is from the object"}
QStore.update(
{"_id" : QT._id},
{
$set: {
"tCode" : testVar,
"name" : "verion 6"
}
}
)
in the schema of the QStore, tCode is defined as {object} which I thought would be right... where am I wrong? :-)
regards,
Paul
Assuming you're using aldeed:simple-schema and everything else is okay (which is tough to tell with only the code snippet above), it's most likely you're missing the blackbox flag in your schema definition:
blackbox
If you have a key with type Object, the properties of the object will be validated as well, so you must define all allowed properties in the schema. If this is not possible or you don't care to validate the object's properties, use the blackbox: true option to skip validation for everything within the object.
I imagine there must me a solution for this, I haven't found one however.
I receive JSON responses of this structure:
{
description: SomeString,
type: ACTIVITY,
timestamp: 1224043200000,
creationTime: 1224043200000,
userIdentification: 1111-2222-3333,
value: 2000
}
"Activity" is the name of my CoreData entity. How do I map this JSON to my data model? All examples I found so far assume a JSON similar to this format:
{
activity: {
description: SomeString,
timestamp: 1224043200000,
creationTime: 1224043200000,
userIdentification: 1111-2222-3333,
value: 2000
}
}
I'm assuming that you have multiple possible different types, each with an associated entity...
Define a mapping for each entity. Don't connect these directly to the response descriptors. Instead, create an RKDynamicMapping instance with a block (setObjectMappingForRepresentationBlock:, or a matcher) which checks the type of the data coming in and returns the appropriate mapping.
If your responses contain multiple different types in a single response then you may want to look at combining the above with KVC validation to reject any objects created with the wrong type. You would also need some different response descriptors or something to apply each of the different entity mappings...
You can look in the ObjectMapping section of the RestKit repo on github. To map your json response you can make use of the nil keyPath as explained here https://github.com/RestKit/RestKit/wiki/Object-mapping#mapping-values-without-key-paths.
As Wain said, you should use Dynamic Mapping to decide which class will be mapped with the json object that you are receiving depending on the value that certain attribute have. How to use Dynamic Mapping is explained here: https://github.com/RestKit/RestKit/wiki/Object-mapping#dynamic-object-mapping. I know it's late, but this could help somebody in the future.