I am trying to generate python client from a swagger yaml file. It works fine, except that the response models are all snake cased(words sep. by underscores) instead of camel cased. I provided the camel cased versions like this:
definitions:
serviceResponse:
type: object
properties:
serviceResponseInternal:
type: object
The generated code has a ServiceResponse object which has an internal field service_response_internal. I would like it to respect the convention and just have serviceResponseInternal instead of underscored seperated names. How do I achieve this?
Assuming you're using Swagger Codegen, you can customize the toVarName in the Python code generator:
https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/java/io/swagger/codegen/languages/PythonClientCodegen.java#L180
Can you elaborate on why you don't want to go with snake case for model properties (which should conform to Python style guide)?
UPDATE: On May 2018, about 50 top contributors and template creators of Swagger Codegen decided to fork Swagger Codegen to maintain a community-driven version called OpenAPI Generator. Please refer to the Q&A for more information.
Related
Swagger & Swagger UI use "Schemas" and "Models" interchangeably. I'd like to refer to them as Models on my Swagger UI instance (rather than Schemas), but can't find where to make this change.
I've attached 2 images that show where I'm referring to. I'd like to erase all references of "Schemas" from the page, and replace them with "Model", similar to how it appears on many of Swagger's test sites (example: petstore.swagger.io) that they've created.
Image 1
Image 2
Swagger & Swagger UI use "Schemas" and "Models" interchangeably.
Just to clarify - Swagger UI uses "Schema" when rendering OpenAPI 3 definitions, and "Model" when rendering OpenAPI 2.0 definitions. With this in mind, "Model" is sort of an outdated term.
If you still want to see the "Model" label in Swagger UI regardless of your OpenAPI version, you'll have to fork Swagger UI, change the label in the code, and build and use your own version. (And rebuild it whenever you want to use a newer Swagger UI release.)
The lines you need to change are:
src/core/components/model-example.jsx
{isOAS3 ? "Schema" : "Model" }
change to
"Model"
src/core/components/models.jsx
<span>{isOAS3 ? "Schemas" : "Models"}</span>
change to
<span>"Models"</span>
I'm currently looking into using our swagger-file that's mainly used for documentation to be used to generate client side SDKs.
I have noticed that our swagger file (that's in swagger 2.0 json format) contains references to defentitions like this:
"$ref":"#/definitions/My%20Awesome%20Object"
When I generate C# SDK, this translates to code that looks something like this:
ApiResponse<My20Awesome20Object>
Removing the %20 from the swagger file solves this issue, but talking to the web backend guys, they say that it's in there as it won't validate otherwise, and I can't find the refernce, but I remember that I found a reference in the swagger-codegen pages that states that the $ref field should be URI encoded, so it seems to be correct.
My current plan is to do a simple script that just strips out the %20 to generate proper references to classes. But that feels like a ugly workaround. Do you have any suggestion how to solve this in a nicer way that is complient to the standard while getting proper code?
Cheers,
Markus
$ref values are URIs. %20 is there because the schema names in the definitions section contain spaces, like so:
"definitions": {
"My Awesome Object": { // <--- $ref: "#/definitions/My%20Awesome%20Object"
"type": "object",
...
}
}
Some tools have problems with handling non-alphanumeric characters in schema names; this includes spaces, < >, « » and the like. Maybe this was why OpenAPI 3.0 restricted valid component names to A-Z a-z 0-9 - . _.
The best fix is to both remove %20 from the $refs AND remove spaces from the schema names in the definitions section. This way the schema names will be forward-compatible with OpenAPI 3.0 if/when you migrate to a newer OpenAPI version.
Some days ago I started a REST API in JavaEE 7, I implemented a single class with three methods and implemented succesfully Swagger and Swagger-UI in the project, which showed the three endpoints I implemented succesfully in the generated JSON.
However, I migrated to JavaEE 8, and after this change Swagger detects several unknown endpoints, like the "default" ones (this capture shows only part of all of them):
Investigating a bit I discovered that these endpoints may belong to a JPA REST API in Eclipselink implementation, as described here https://oracle-base.com/articles/misc/oracle-rest-data-services-ords-open-api-swagger-support and here https://www.eclipse.org/eclipselink/documentation/2.4/solutions/restful_jpa004.htm#CHDFCFFA
Despite they appear in the generated JSON, all of them contain variable paths, so I can't access them following the path given by Swagger, even inventing some parameters like "version" using the webs above examples.
The Swagger version I use is v3, aka OpenAPI version. I specify OpenAPI properties with #OpenAPIDefinition in the endpoint class, which also contains a #Tag annotation to group them and the three methods contain #Operation tag with their own #ApiResponse. There is no more Swagger/OpenAPI annotations/files/classes written by me.
The question is, how can I make Swagger ignoring these endpoints?
Thanks
Finally I have found a solution. The case is that Swagger scanner engine scans the whole project, ignoring if the class and his methods have #Operation or not. If my hypothesis is true, some Eclipselink classes could have Swagger annotations (I'm not sure), so when Swagger scans, if finds them and add them to the JSON/YAML.
The solution is creating/adding to the existant openapi.yaml (it can have several names and can be in several locations, as enumerated here: https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Integration-and-configuration#known-locations) this:
resourceClasses:
- com.path.to.your.package.Resource
prettyPrint: true
cacheTTL: 0
scannerClass: io.swagger.v3.jaxrs2.integration.JaxrsAnnotationScanner
readAllResources: false
Instead of resourceClasses it can be written resourcePackages, and then it should be specified the whole package and the class in the same style as used to specify the package. To be honest, this property does not affect to my problem.
The solution comes on setting readAllResources to false. The reason is here, in a note: https://github.com/swagger-api/swagger-core/wiki/Swagger-2.X---Annotations#operation
Blockquote
Note: swagger-jaxrs2 reader engine includes by default also methods of scanned resources which are not annotated with #Operation, as long as a jax-rs #Path is defined at class and/or method level, together with the http method annotation (#GET, #POST, etc).
I hope this solution serves for anyone if he/she has to face the same problem.
I'm working with IIB v9 mxsd message definitions. I'd like to define one of the XML elements to be of type xsd:anyType. However, in the list of types I can choose from, only anySimpleType and anyUri are possible (besides all other types like string, integer, etc.).
How can I get around this limitation?
The XMLNSC parser supports the entire XML Schema specification, including xs:any and xs:anyType. In IIBv9 you should create a Library and import your xsds into it. Link your Application to the Library and the XMLNSC parser will find and use the model. You do not need to specify the name of the Library in the node properties; the XSD model will be automatically available to the entire application.
You do not need to use a message set at all in IIBv9 and later versions.
The mxsd file format is used only by the MRM (not DFDL) parser.
You shouldn't use an MXSD to model your XML data, use a normal XSD.
MXSD is for modelling data for the DFDL parser, but you should use the XMLNSC parser for XML messages and define them in XSDs, in which you can use anyType.
As far as I know DFDL doesn't support anyType.
I've read other questions about how to order using apisSorter and operationsSorter.
However in my case I want to be able to define a custom order to list several POST methods in a logical workflow order.
The catch is, since I'm using swagger-codegen, I'm only writing the swagger spec in a yaml file and can't see how to define a custom order then?