OAS: update definition

Support
, ,
1

We are using the OAS option for Tyk (Open Source), but once we have created a new OpenApiSpecification definition, we are not able to tweak the Tyk-specific options.

In our case, we want to configure a go-plugin middleware, which is something we cannot do with the ‘x-tyk-api-gateway’ section of the OAS spec. When we try to configure the Tyk settings by making a PUT request on /tyk/apis/xxx then we get the following error:
{“status”:“error”,“message”:“the supplied API definition is in Tyk native format, please use OAS format for this API”}
Doing a PATCH on the /tyk/apis/oas/xxx endpoint does not allow us to configure middlewares.

Would it be possible to remove the check for OAS format, so we can tweak all settings ? Or do you plan to support all Tyk options in the OAS file spec ?

Kind regards, Barry

2

Update: After some more investigation, we managed to make it work: Turns out that we can call the ‘Create’ endpoint multiple times; if the api-definition already exists the tyk-gateway will simply update the existing definition.

curl -X POST -H 'x-tyk-authorization: xxxx' -H 'Content-Type: application/json' -d @api-def.json http://localhost:8080/tyk/apis

You can call the create endpoint many times, I suppose it creates a new version?

Barry

3

Unfortunately there is still an issue with OAS definitions: once we use the OAS endpoint we loose all Tyk native configuration. The opposite is also true: after we update the Tyk native configuration, the api-definition has the ‘is_oas’ set to false.

Question for Tyk devs: how are we supposed to configure OAS endpoints that need native Tyk API definition features ?

4

Hi @Barry_Lagerweij

Thanks for your questions, it’s great that you’re trying out the new and evolving OAS support in Tyk!

Tyk’s support for OAS is currently in an experimental phase: we are working towards full parity with the classic Tyk API Definition but we are not there yet.

For the use case you describe, we don’t yet support custom middleware configuration via OAS; this is something we are actively working on and looking to release in the next few months.

We’ll take a look at the behaviour you’ve reported with multiple calls to the Create endpoint, as this isn’t the correct way to update an API definition.

If you want to update an existing OAS API Definition you should use the PUT method, unless you’re looking to replace it with another OAS Document in which case you should use PATCH.

Neither of these will enable you to configure custom middleware due to the fact we don’t yet support this with our OAS implementation.

In case you’ve not already seen it, you can find more details here: Update existing Tyk API with changes in your OpenAPI definition

To answer your most recent question: at this stage because we don’t have feature parity between OAS and Tyk’s classic API Specification, it’s just not possible to configure OAS endpoints with features we don’t currently support.

We are adding new features with every minor and major release of the Tyk Gateway, so please keep an eye on our release notes for the updates. More details on the supported features so far: OAS Reference

Are there any specific features that are currently not supported (other than custom middleware!) that you are looking to configure in your OAS APIs?

I hope this helps, but please don’t hesitate to get in touch if you have any other questions.

Kind regards,
Andy.

1 Like