swift-openapi-generator
swift-openapi-generator copied to clipboard
apple
Generate Swift client and server code from an OpenAPI document.
Might result in better performance as it'd avoid existentials in the transport and middlewares properties. However, we also should keep in mind the use case where the exact transport and...
An example of a schema that today the generator produces non-compiling Swift code for, as both enum cases are named `_1`. ```yaml type: string enum: - "+1" - "-1" ```...
Currently we have symbols defined in the runtime package that the generator needs to generate code for. In order to facilitate this, the generator package contains a `Constants` file where...
OpenAPI supports expressing quite a few different ways of encoding parameters, especially query items. The generator currently only supports the defaults, but not the other ones. Is needed to support...
Currently, when errors are thrown in a transport, we attach as much context as we have at that point (the Input value, operationId, etc). But when an error is thrown...
Currently, a generated server does not validate the content-type header before it tries to parse the request body contents, which means that if incorrect request body data is sent, the...
Should probably be another docc article in the Contributing section. Should include how to correctly stage changes to the runtime library, optionally to transports, and at which point the generator...
The word "content" should be reserved for the `content type: media type` map. For bodies, we use the term "body".
This already works for many types and properties, but not for all. We should ensure that all content from the OpenAPI doc generated in Swift includes a comment linking it...
Currently, only `type: string` + `format: binary` is supported, and represents raw data (an octet stream). OpenAPI also supports base64-encoded data, represented as the following JSON schema: ```yaml type: string...