I found it a little jarring that we accept swaggerString, which is a string, when specifying an OpenAPI specification for the entire API, versus data, which is an any, when specifying the OpenAPI integration object subset of the specification, for RawDataRoutes.
I would have expected them to be consistent. For example, perhaps accept a string | Object and automatically serialize the object as a JSON string if Object is used.
Even nicer than Object, we could actually accept the strongly typed OpenAPI types that we have lurking in this package. I'm not sure it's worth the effort as it may just cause troubles if we don't keep our types up to date, but I could imagine for anybody spelunking at this level, it'd be a nice touch.
Also, a minor nit, we should move away from calling this "Swagger" and instead begin calling it "OpenAPI," since this new name supersedes the old one.
I found it a little jarring that we accept
swaggerString, which is astring, when specifying an OpenAPI specification for the entireAPI, versusdata, which is anany, when specifying the OpenAPI integration object subset of the specification, for RawDataRoutes.I would have expected them to be consistent. For example, perhaps accept a
string | Objectand automatically serialize the object as a JSON string ifObjectis used.Even nicer than
Object, we could actually accept the strongly typed OpenAPI types that we have lurking in this package. I'm not sure it's worth the effort as it may just cause troubles if we don't keep our types up to date, but I could imagine for anybody spelunking at this level, it'd be a nice touch.Also, a minor nit, we should move away from calling this "Swagger" and instead begin calling it "OpenAPI," since this new name supersedes the old one.