Cached openapi spec

[RudiThoeni]

Hi @gappc

I added a client side cached openapi spec at https://api.tourism.testingmachine.eu/json/swagger.json (Cache-Control: public,max-age=86400) could this be useful for the databrowser? The openapi spec is recreated on each deploy.....

For the spec located at https://api.tourism.testingmachine.eu/swagger/v1/swagger.json i was able to add server side caching.....

I saw the spec is about 900kb, so the caching as you said should improve databrowser loading significantly

cheers Rudi

[gappc]

@RudiThoeni nice work, here my observations:

• https://api.tourism.testingmachine.eu/json/swagger.json => caching works as expected, I see the cache headers in the response and the downloaded file size is reduced. I see that the changes are already deployed to production (https://tourism.opendatahub.com/json/swagger.json). Should I switch to these files?

• https://api.tourism.testingmachine.eu/swagger/v1/swagger.json => caching seems not to work, the response contains no cache headers. What do you mean with "server side caching"?

thx

[RudiThoeni]

Yes switch to this files (https://tourism.opendatahub.com/json/swagger.json) production (https://api.tourism.testingmachine.eu/json/swagger.json) test

Explanation: With my used library in the past the openapi spec was generated always on the fly, so with the server side caching i meant that i was able to cache this openapi generation process which already gives some performance advantage. Unfortunately i cannot add the client side cache headers to the generated route so i had to use another route for this ;)

cheers Rudi

[gappc]

@RudiThoeni I've opened PR #466 to change the URL for the OpenAPI file for the tourism domain. Please take a look at it and if you think it's ok, then please merge it.

[gappc]

@RudiThoeni thanks for merging. Should we close this issue?

[RudiThoeni]

sure, i tested and saw on test we have the right url ;)