OAS 3 query parameter description is lost in RAML 0.8
Hello, here it is. I'm also using the code I mentioned in my previous reply for parsing (and switched between Raml08 and Ram10 classes). As you can see below, description is missing for the parameter name def in RAML 8.0. About amf prefixes, is there a way to remove it before generating RAML file? Because the CMS I'm using, does not recognize these amf variables and sees them as invalid, but If I remove them manually it becomes valid.
Input
{
"openapi":"3.0.1",
"info":{
"title":"API Endpoints",
"version":"v1"
},
"servers":[
{
"url":"http://localhost:8080",
"description":"Generated server url"
}
],
"paths":{
"/api/users":{
"get":{
"tags":[
"user-controller"
],
"summary":"getAllUsers() summary..",
"operationId":"getAllUsers",
"parameters":[
{
"name":"def",
"in":"query",
"description":"default parameter description..",
"required":true,
"schema":{
"type":"string"
}
}
],
"responses":{
"default":{
"description":"default response",
"content":{
"application/json":{
"schema":{
"$ref":"#/components/schemas/User"
}
}
}
}
}
}
}
},
"components":{
"schemas":{
"Page":{
"type":"object",
"properties":{
"number":{
"type":"integer",
"format":"int32"
},
"name":{
"type":"string"
},
"content":{
"type":"string"
}
}
},
"User":{
"type":"object",
"properties":{
"name":{
"type":"string"
},
"username":{
"type":"string"
},
"password":{
"type":"string"
}
}
}
}
}
}
Output RAML 0.8
#%RAML 0.8
title: API Endpoints
baseUri: http://localhost:8080
(amf-serverDescription): Generated server url
version: v1
/api/users:
get:
displayName: getAllUsers
(amf-summary): getAllUsers() summary..
(amf-tags):
- user-controller
queryParameters:
def:
type: string
required: true
(amf-defaultResponse):
default:
description: default response
body:
application/json:
formParameters:
name:
type: string
required: false
username:
type: string
required: false
password:
type: string
required: false
Output RAML 1.0
#%RAML 1.0
title: API Endpoints
baseUri: http://localhost:8080
(amf-serverDescription): Generated server url
version: v1
/api/users:
get:
displayName: getAllUsers
(amf-summary): getAllUsers() summary..
(amf-tags):
- user-controller
queryParameters:
def:
**description: default parameter description..**
required: true
type: string
(amf-defaultResponse):
default:
description: default response
body:
application/json:
type: object
additionalProperties: true
properties:
name:
type: string
required: false
username:
type: string
required: false
password:
type: string
required: false
Originally posted by @Cytor in https://github.com/raml-org/webapi-parser/issues/81#issuecomment-671763791
Reported to amf in https://github.com/aml-org/amf/issues/581
https://github.com/aml-org/amf/issues/581#issuecomment-693564874
Good morning @postatum! I've been reviewing and have some comments regarding this issue, hope this helps:
1. When changing specs in resolution (e.x. OAS30 -> RAML10) the _compatibility pipeline_ must be used in resolution 2. Although it's technically possible, we don't support conversion to RAML08 (as far as the raml08resolver doesn't support compatibility pipeline)I've reproduced your exact case in javascript and the code is the following:
const amf = require('amf-client-js') const spec = `{ "openapi":"3.0.1", "info":{ "title":"API Endpoints", "version":"v1" }, "paths":{ "/api/users":{ "get":{ "operationId":"getAllUsers", "parameters":[ { "name":"def", "in":"query", "description":"default parameter description..", "required":true, "schema":{ "type":"string" } } ] } } } } ` async function main () { await amf.AMF.init() const parsedModel = await new amf.Oas30Parser().parseStringAsync(spec) const model = await new amf.Raml10Resolver().resolve(parsedModel, 'compatibility') const str = await new amf.Raml10Renderer().generateString(model) console.log(str) } (async () => {main()})()Resulting in the exact same generated API Spec in RAML1.0 that you appended:
#%RAML 1.0 title: API Endpoints version: v1 /api/users: get: displayName: getAllUsers queryParameters: def: description: default parameter description.. required: true type: stringI'm closing this issue as won't fix. If there are any questions I'll be following this thread or you can open a new issue with updated information if neccesary.
Thank you for reading!
Related to #80