is it correct to have different types in data array ? didn't found answer in specification, but looks wrong.
{
"data": [
{
"type": "type1",
"id": "id1"
},
{
"type": "type2",
"id": "id2"
}
]
}
Polymorphic collections are supported by JSON:API specification. Your example is a valid JSON:API document.
This is not mentioned explicitly in the specification. It is only implicitly stated by not requiring all resource objects included as primary data to have the same type.
Please note that it could even include two resource objects with the same id as long as they have different type.
Related
Regarding "position" below. I am trying to find what is the best way to define the value of "position" attribute as Location not known. I means how to represent location not known in orion database.
{
"contextElements": [
{
"type": "City",
"isPattern": "false",
"id": "Madrid",
"attributes": [
{
"name": "position",
"type": "geo:point",
"value": "LocationNotKnown"
}
]
}
],
"updateAction": "APPEND"
}
Many thanks.
At the present moment (up to Orion 2.3.0) geo:point attribute needs a valid point as value, so thinks like "LocationNotKnown" will not work.
However, we have been discussing the possibility of allowing null or "" as valid value for geo:point (and other similar attribute types) to mean "no location" (or "no date", in the case of DataTime). You can join the discussion on the corresponing github issue and provide your opinion there.
On the meanwhile, the recommended workaround is to remove the attribute. Thus, if your entity includes the "location" attribute (with a valid geo:point as value) then it is localized. If your entity doesn't include the "location" attribute is not localized.
In compare to draft-07 it defines:
{
"type": ["object", "boolean"],
"properties": {
...
"$ref": {
"type": "string",
"format": "uri-reference"
},
}
...
}
Currently I am trying to write validator for openapi. But validation fails because openapi schema (yes, it is schema from google apis) does not define $ref as allowed property for schema.
Is this a typo? What is recommendation about how to check $ref property?
$ref is a JSON Reference. It's not part of the schema definition, instead it's part of the reference definition:
"reference": {
"type": "object",
"description": "A simple object to allow referencing other components in the specification, internally and externally. The Reference Object is defined by JSON Reference and follows the same structure, behavior and rules. For this specification, reference resolution is accomplished as defined by the JSON Reference specification and not by the JSON Schema specification.",
"required": [
"$ref"
],
"additionalProperties": false,
"properties": {
"$ref": {
"type": "string"
}
}
},
And then other definitions where $ref is allowed use oneOf something or reference (example):
"schemaOrReference": {
"oneOf": [
{
"$ref": "#/definitions/schema"
},
{
"$ref": "#/definitions/reference"
}
]
},
By the way, there are currently two different draft OAS3 JSON Schemas in the official OpenAPI Specification repository. Feel free to try them instead, and provide your feedback in the corresponding discussions.
[WIP] Alternative OAS3 JSON Schema (link to schema)
OpenAPI v3 JSON Schema (link to schema)
Given a resource like:
GET: /api/examples/1
{
"id": 1,
"direction": "North"
}
Which also supports POST, PUT, how should the possible values for "direction" be specified?
Additionally, is there a solution which allows the consumer to know which values will be available if those values are contextual? e.g. if the example is made more complicated:
GET: /api/examples/
{[
{
"id": 1,
"startLocation": "Kentucky, USA",
"direction": "North"
}
{
"id": 2,
"startLocation": "North Pole",
"direction": "South"
}
}]
(with something vaguely like):
"options": [
{
"value": "North",
"validWhen": "startLocation !== `North Pole`"
},
{
"value": "East",
"validWhen": "true"
},
...
]
Is there a better solution than another resource linked from each example which returns the currently valid options? If not, how does the consumer know that changing "startLocation" changes the valid set of values for "direction"?
I think what you might be looking for is a JSON-Schema. This allows you to strictly describe what options are available in your JSON document, and you can link to the document using a describedBy link.
To expand on what #Justas said in his comment, if I understand your requirements correctly, your resource might look something like:
GET /examples/1
{
"startLocation": "Kentucky, USA",
...
"_links": {
"travel-north": "/some/url",
...
}
}
I'm trying to validate that the data I am returned it sensible. Validating data types is done. Now I want to validate that I've received all of the data needed to perform a task.
Here's a representative example:
{
"things": [
{
"id": "00fb60c7-520e-4228-96c7-13a1f7a82749",
"name": "Thing 1",
"url": "https://lolagons.com"
},
{
"id": "709b85a3-98be-4c02-85a5-e3f007ce4bbf",
"name": "Thing 2",
"url": "https://lolfacts.com"
}
],
"layouts": {
"sections": [
{
"id": "34f10988-bb3d-4c38-86ce-ed819cb6daee",
"name": "Section 1",
"content:" [
{
"type": 2,
"id": "00fb60c7-520e-4228-96c7-13a1f7a82749" //Ref to Thing 1
}
]
}
]
}
}
So every Section references 0+ Things, and I want to validate that every id value returned in the Content of Sections also exists as an id in Things.
The docs for Object.assert(..) implies that I need a concrete reference. Even if I do the validation within the Object.keys or Array.items, I can't resolve the reference at the other end.
Not that it matters, but my context is that I'm validating HTTP responses within IcedFrisby, a Frisby.js fork.
This wasn't really solveable in the way I asked (i.e. with Joi).
I solved this for my context by writing a plugin for icedfrisby (published on npm here) which uses jsonpath to fetch each id in Content and each id in Things. The plugin will then assert that all of the first set exist within the second.
I am sending a POST request to http://orion.lab.fiware.org:1026/v2/entities/85/attrs?type=UrbansenseLocation in order to update atime and bundle attributes:
{
"atime":{
"type":"Number",
"value":1476370651},
"bundle":{
"type":"Number",
"value":1}
}
and a GET request to the same entity receives the following response:
{
"id": "85",
"type": "UrbansenseLocation",
"atime": {
"type": "Number",
"value": 1476370000,
"metadata": {}
},
"bundle": {
"type": "Number",
"value": 1,
"metadata": {}
},
//some other attributes
}
Please, note the mismatch on the value field of the atime attribute!!! Why is such thing happening?
Thanks.
I understand that atime is meant to be a datetime. In that case, I'd suggest to use the DateTime attribute type. This would provide a better semantic for the attribute and should avoid any number rending problem (as the ones that are being discussed right now at github).
More information about the DateTime type at the NGSIv2 specification (section "Special Attribute Types") and this document (look for the "Datetime support" slide).