We are in the process of rewriting a gRPC service in ServiceStack. grpc-gateway
generated the OpenAPI definitions for us based on the .proto definition and this is how we exposed the application to web clients. In particular, our existing Angular application uses ng-swagger-gen
to consume these definitions and generates a typed service client.
As a stop-gap prior to trying out typed SS clients, we are attempting to configure SS to generate definitions that match as close as possible what we originally had coming out of grpc-gateway
.
With that in mind we have a few questions/roadblocks:
- Regardless of whether
HostConfig.DefaultContentType
is set, a requiredAccept
parameter is appended to everyOpenApiPath
definition (changes the signature of all generated functions to include this non-optional header param) and doesn’t appear to be configurable. - Tries to generate unique
OperationId
s by default instead of the conventional DTO name. Luckily ours are pretty consistent so we can knock out most of them with a filter along the lines ofoperation.OperationId = Regex.Replace(operation.OperationId, "Request.*$", "")
but it would be nice ifGetOperationName
tried to use the conventional name first unless there is a conflict. - There appears to be no way to globally default to emitting enum types instead of strings in the definition. I understand we can manually annotate DTOs with
[ApiAllowableValues(...)]
, but this is tricky to do everywhere, particularly in cases where we are reusing OrmLite domain models in request/response DTOs. Is there a better option? - It appears that
query
andpath
parameter names do not respect theUseCamelCaseSchemaPropertyNames
config option, nor is there a more specific option. Is this intentional? It results in inconsistent casing for parameters on the same request.
I am most concerned with (3) and (4) as these would be the most difficult to hack around with the available operation filters. We could really use a solution around (3) in particular.
Thanks in advance and I’d be happy to contribute some of these changes to OpenApiFeature
if we can agree upon behavior!