Is there a way to split a Swaggerfile / OpenAPI definition into multiple files? - json

Is there a way to split a swaggerfile / OpenAPI specs file, either JSON or YAML, encoding every $ref into a separate file? Because I found a lot of solutions to achieve the opposite (multiple files -> single file), but none for this.
What I'd like to achieve is the following:
I have a huge JSON swaggerfile that contains internal $refs.
I'd like to have a single file for each and every object or path definition, and, in the root file, references (local or absolute) to these files. This way I can edit the root file to easily obtain a minimal subset of the paths and objects that I need.
{
"in": "inputField",
"required": true,
"schema": {
"$ref": "#/components/schemas/MyObject"
},
"components": {
"schemas": {
"MyObject": {
"type": "object",
"properties": {
"value": {
"type": "string"
}
}
}
}
},
"____comment": "I want MyObject definition in MyObject.json file and the $ref to that file"
}

Yeah, its possible, you must only use regex, and detect depedencies etc.
regex example from my project
new Regex("\"#/definitions/(.*)\"");
new Regex("#\\/definitions\\/(.*?)\\\"");
new Regex("\"" + key + "\": ");
etc.
You must replace elements with dependencies, and save to file. I do sth like that to recive jschema from model. Your case,is a little diffrent, but smilar.

Related

extract certain json object nifi Json

Im trying to extracting json objects and store it to hdfs. I'm targeting message attribute which is a6,b6,c6,d6,e6
json sample
{
"#timestamp":"2020-07-06T07:35:29.047Z",
"#metadata":{
"beat":"filebeat",
"type":"_doc",
"version":"7.7.1"
},
"log":{
"offset":91,
"file":{
"path":"C:\\Program Files\\Filebeat\\test-kafka\\test_csv.csv"
}
},
"message":"a6,b6,c6,d6,e6",
"input":{
"type":"log"
},
"ecs":{
"version":"1.5.0"
},
"host":{
"name":"host"
},
"agent":{
"version":"7.7.1",
"type":"filebeat",
"ephemeral_id":"0b4a288f-f7ac-4db9-835e-60ca07a45fff",
"hostname":"host",
"id":"5e2fec03-bbdc-4f91-acc9-4ab36c7268db"
}
}
GenerateFlowFile properties
JsonEvaluatePath properties
but problem JsonEvaluatePath not working as i expected, i thought it will extracting only message attribute.
hadoop#ambari:~$ hdfs dfs -cat /user/test/5a422f02-9074-4384-a3c9-f3e3ce7c2e40
{
"#timestamp":"2020-07-06T07:35:29.047Z",
"#metadata":{
"beat":"filebeat",
"type":"_doc",
"version":"7.7.1"
},
"log":{
"offset":91,
"file":{
"path":"C:\\Program Files\\Filebeat\\test-kafka\\test_csv.csv"
}
},
"message":"a6,b6,c6,d6,e6",
"input":{
"type":"log"
},
"ecs":{
"version":"1.5.0"
},
"host":{
"name":"host"
},
"agent":{
"version":"7.7.1",
"type":"filebeat",
"ephemeral_id":"0b4a288f-f7ac-4db9-835e-60ca07a45fff",
"hostname":"host",
"id":"5e2fec03-bbdc-4f91-acc9-4ab36c7268db"
}
}
Am i missing something?
Since you used EvaluateJsonPath with destination set as flow file attributes, it extracted message into a flow file attribute and the content of the flow file is still the same as it was before. You would need to use another processor like AttributesToJson before PutHDFS to rewrite the flow file content with the attributes you want. An alternative might be to set EvaluateJsonPath destination to flow file content, but I'm not sure if that produces valid json.

Split OpenApi Paths into multiple path definition files

I want to split my paths (which are quite many) more easily into their own files.
Let's say I've got two major paths /user and /anotherPath with several subpaths. Now I've got an OpenApi spec file, whose paths are being referenced to an index file which holds references to each paths. Defining EVERY path with its' reference works, but is clumsy to write.
I want something like this:
openapi.json
{
...
"paths": {
"$ref": "paths/index.json"
}
...
}
paths/index.json
{
"/user": { // and everything that comes after user, e.g. /user/{userId}
"$ref": "./user-path.json"
},
"/anotherPath": { // and everything that comes after anotherPath, e.g. /anotherPath/{id}
"$ref": "./anotherPath-path.json"
}
}
paths/user-path.json
{
"/user": {
"get": {...}
},
"/user/{userId}": {
"get": {...}
}
}
paths/anotherPath-path.json
{
"/anotherPath": {
"get": {...}
},
"/anotherPath/{id}": {
"get": {...}
}
}
This way, whenever I add another path to /user or /anotherPath, I can simply edit their respective path file, e.g. paths/user-path.json.
EDIT1: Apparently, this topic is being discussed already.. For anyone interested: https://github.com/OAI/OpenAPI-Specification/issues/417 . By the way, I know that a $ref is not valid for the paths Object, but once figuring out how to properly split, this may not be necessary anymore.
OpenAPI does not have a concept of sub-paths / nested paths, each path is an individual entity. The paths keyword itself does not support $ref, only individual paths can be referenced.
Given your user-path.json and anotherPath-path.json files, the correct way to reference path definitions is as follows:
{
...
"paths": {
"/user": {
"$ref": "paths/user-path.json#/~1user" // ~1user is /user escaped according to JSON Pointer and JSON Reference rules
},
"/user/{id}": {
"$ref": "paths/user-path.json#/~1user~1%7Bid%7D" // ~1user~1%7Bid%7D is /user/{id} escaped
},
"/anotherPath": {
"$ref": "paths/anotherPath-path.json#/~1anotherPath" // ~1anotherPath is /anotherPath escaped
},
"/anotherPath/{id}": {
"$ref": "paths/anotherPath-path.json#/~1anotherPath~1%7Bid%7D" // ~1anotherPath~1%7Bid%7D is /anotherPath/{id} escaped
}
}
...
}
YAML version:
paths:
/user:
$ref: "paths/user-path.json#/~1user"
/user/{id}:
$ref: "paths/user-path.json#/~1user~1%7Bid%7D"
/anotherPath:
$ref: "paths/anotherPath-path.json#/~1anotherPath"
/anotherPath/{id}:
$ref: "paths/anotherPath-path.json#/~1anotherPath~1%7Bid%7D"
If you want to use $ref in arbitrary places (other than where OAS allows $refs), you'll have to pre-process your definition using a parser/tool that can resolve arbitrary $refs; this will give you a valid OpenAPI file that can be used with OpenAPI-compliant tools. One such pre-processing tool is json-refs, you can find an example of pre-processing here.

Check with jsonschema if path is valid

I am trying to write a json schema including the feature to check if a path is valid and exist.
For example I want to validate this json:
{
"paths": ["/path/to_check", "../path/not/valid", "../../path/exists"]
}
My current schema is:
{
"type": "object",
"properties": {
"paths": {
"type": "array",
"items": {
"type": "string"
}
}
}
}
Is there a way to indicate that items must contain valid/existing paths?
You can use regex, but there's no way to determine if a path is a real path according to a file system. JSON Schema works with JSON data... that's all, nothing more. It has no notion of a file system.
I've been googling for the same thing and was coming to the same conclusion that #Relequestual posted (who is the authority on such things).
What may be of interest is that the pydantic library extends their JSON Schema with a bunch of extensions for complex string sub-types, including file-path, directory-path and path (and many, many more).
This could be useful either directly, or to adopt as a quasi-standard for a custom implementation.

It is possible to generate a JSON schema for dynamic attributes

The problem is that in my app we have a data structure like this:
{
"adults": {
"jagger_mick_dateOfBirth": {
"name": "Mick"
"lastName": "Jagger",
"more atributes": ""
},
"jolie_angelina_dateOfBirth": : {
"name": "Angelina"
"lastName": "Jolie",
"more atributes": ""
}
},
"children": {
"osbourne_ozzy_dateOfBirth": : {
"name": "Ozzy"
"lastName": "Osbourne",
"more atributes": ""
}
}
}
As you can see, for each Adult & Children, we use a dynamic attribute to identify each object. BUT inside is the same object.
Right now I am in the process to generate JSON Schemas (v4) for this data structure.
My problem is i cannot find a property to evaluate dynamic attributes, althought the object is the same, just the key is different.
I know that it is bad coding, but it is possible to generate a JSON Schema (v4) to validate a dynamic attribute (key) ?
Thanks in advance.
P.D.
If you are wondering why we use this approach, is because we can access directly to the object, instead of search for it.
If your dynamic object attributes can be described with a regular expression, you can use patternProperties keyword.

Node.js SOAP client parameter formatting

I'm having trouble properly formatting one particular soap parameter using the node-soap module for node.js as a client, to a 3rd-party SOAP service.
The client.describe() for this method says this particular input should be in the shape of:
params: { 'param[]': {} }
I have tried a bunch of different JSON notations to try to fit my data to that shape.
Examples of formats that do NOT work:
"params": { "param": [ {"myParameterName": "myParameterValue"} ] }
"params": [ "param": { "name": "myParameterName", "_": "myParameterValue"} ]
"params": { "param" : [ {"name": "myParameterName", "_": "myParameterValue"} ] }
"params": { "param[]": {"myParameterName": "myParameterValue" } }
"params": { "param[myParameterName]": {"_": "myParameterValue" } }
I must be overlooking something, and I suspect I'm going to feel like Captain Obvious when some nice person points out what I'm doing wrong.
Here is what DOES work, using other soap clients, and how they handle the "named parameter with a value"
soapUI for this method successfully accepts this particular input via XML in the shape of:
<ns:params>
<ns:param name="myParameterName">myParameterValue</ns:param>
</ns:params>
Also, using PHP, I can successfully make the call by creating a stdClass of arrays like so:
$parms = new stdClass;
$parms->param = array(
array(
"name"=>"myParameterName","_"=>"myParameterValue"
)
);
and then eventually passing
'params' => $parms
to the PHP soap client
Many thanks!
To get a better look at what XML was being generated by node-soap, I added a console.log(message) statement to the node_modules/soap/lib/client.js after the object-to-XML encoding. I then began experimenting with various JSON structures to figure out empirically how they were mapping to XML structures.
I found a JSON structure for node-soap to generate the XML in my 3rd-party's required named-parameter-with-value format. I was completely unaware of the "$value" special keyword. Looks like this may have been added in the 0.4.6 release from mid-June 2014. See the change history
"params": [
{
"param": {
"attributes": {
"name": "myParameterName"
},
$value: "myParameterValue"
}
}
]
(note the outer array, which gives me the luxury of specifying multiple "param" entries, which is sometimes needed by this particular 3rd-party API)
generates this XML:
<tns:params>
<tns:param name="myParameterName">myParameterValue</tns:param>
</tns:params>
which perfectly matches the structure in soapUI (which I already knew worked) of:
<ns:params>
<ns:param name="myParameterName">myParameterValue</ns:param>
</ns:params>