Hi @Barry_Lagerweij,
Thank you for your questions.
Our git repo uses YAML format for the specs, not JSON. Not a showstopper, since we can convert using yq.
Yes, this is the correct approach for now and weāre looking at supporting YAML as a format in the future.
We would like to use a custom golang plugin. So far weāve not been able to configure this using x-tyk-api-gateway section, it seems not all properties we have for the regular api-definitions are available?
As of now, the Tyk OAS API Definition doesnāt yet have full parity with the configuration options in the Classic API Definition. Custom middleware support, is on our radar and among our immediate priorities
Our plugin would need access to some configuration data. We tried to add āconfig_dataā, but any unmapped or unsupported properties are simply ignored and get lost. In an ideal world, the plugin would be able to access the OAS specs directly (similar to ctx.GetDefinition(r) which is available to plugins currently. Since we can have many mappings in a single OAS document, we would prefer to access the specific endpoint (including the path, method, and any parameters). Something like ctx.getOASEndpointDefinition
Config data is another config option that would be added alongside the custom middleware section, and since OAS documentation is part of the OAS API Definition, you would be able in the future to grab anything you need from the OAS documentation within the plugin logic. Weāll be documenting all the options when releasing the support for custom middleware!
We would like a way to access all metadata of the endpoint, including the parameters and any custom attributes. For instance, a way to access the following configuration:
"parameters": [
{
"description": "ID of pet to return",
"in": "path",
"name": "petId",
"required": true,
"schema": {
"format": "int64",
"type": "integer"
},
"x-tyk-permission": "manage",
"x-tyk-type": "provider"
}
],
In the above configuration, the parameter āpetIdā has two custom attributes which may be access by a plugin.
Hope the above makes sense, Iām available to jump onto a meet to discuss further details.
With every custom middleware youāll have access to the path and method of the request, as well as the Tyk OAS API Definition, and based on that I think itās easy to access any data of a path in the OAS documentation.
We really appreciate your input here Barry. It would be great if we could have a discussion about how you would like to use Tyk + OAS in general. Would you be interested if we set up some time to chat?
