Smithy is a protocol-agnostic interface definition language and set of tools for generating clients, servers, and documentation for any programming language.
Context
I have a Smithy model, defining a service, and it's used for both server/client codegen. The service's runtime is a Lambda Function with an API Gateway infront of it. The API Gateway is setup using using CDK's SpecRestApi by leveraging the OpenAPI conversion plugin.
In smithy-build.json, one can define multiple openapi conversions e.g. openapi::restjson and openapi::rpcv2 to end up with 2 different openapi conversions e.g.
and when I look at the diff between the conversions, the only difference in is in the paths section, and to me, it looks like at least with those 2 protocols, the same API Gateway, as defined by a single openapi definition, can support both.
As such, this is a request, to allow for multiple protocols into the same openapi conversion (which can maybe be achieved by merging 2 conversions, so long as they don't overwrite each other)
This is a Feature Request to allow the
openapi
conversion plugin - https://smithy.io/2.0/guides/model-translations/converting-to-openapi.html - to support multiple protocols if the the service as defined in Smithy model support multiple protocols.Context I have a Smithy model, defining a service, and it's used for both server/client codegen. The service's runtime is a Lambda Function with an API Gateway infront of it. The API Gateway is setup using using CDK's SpecRestApi by leveraging the OpenAPI conversion plugin.
The model defines the service to use the aws.protocols#restJson1, and I'm looking into getting it to support smithy.protocols#rpcv2Cbor
The Request
In
smithy-build.json
, one can define multipleopenapi
conversions e.g.openapi::restjson
andopenapi::rpcv2
to end up with 2 different openapi conversions e.g.and when I look at the diff between the conversions, the only difference in is in the
paths
section, and to me, it looks like at least with those 2 protocols, the same API Gateway, as defined by a single openapi definition, can support both.As such, this is a request, to allow for multiple protocols into the same openapi conversion (which can maybe be achieved by merging 2 conversions, so long as they don't overwrite each other)