Discovery
The main function of a discovery agent is to "understand" the configuration of a Gateway and decide what constitutes a "deployed" API in that Gateway's context.
An agent should be able to discover some kind of an API Definition to get a good representation of it in APICentral. That would be expressed in an API Definition language (like OpenAPI v2, v3, Protobuf, etc..) .
So a problem that we seem to have with Kong, is that it doesn't necessarily concern itself with API Definitions at least not the opensource version of it (ie you can't just look at the Kong configuration and find all the Specs for all the APIs it exposes). There might be API Management solutions built on top of it. So it would be useful to determine how Kong is being used by our target base, to see how we can address this problem to better serve their needs.
No ci-cd needed
The enterprise version of Kong supports to assign documentations (specs) to the service object.
The path of the spec file can be retried from the service /services/{service_id}/document_objects or via /document_objects/ to get all available specs.
Example
http ${KONG_ADMIN_URL}/services/e53d9a66-8aa1-4a06-b505-3c677d6b43a1/document_objects ${KONG_TOKEN}
{
"data": [
{
"created_at": 1611938990,
"id": "0cbba354-6a0c-4f40-8d5f-54989b0e8c66",
"path": "specs/httpbin.json",
"service": {
"id": "e53d9a66-8aa1-4a06-b505-3c677d6b43a1"
}
}
],
"next": null
}
The "specs" have to be stored in the Kong Portal.
The spec file can be retrieved from the Kong gateway with the following path http://<admin-url>/default/files/<spec_path>.
The <spec_path> has to be extracted from the previous request.
http ${KONG_ADMIN_URL}/default/files/specs/httpbin.json ${KONG_TOKEN}
{
"checksum": "82dac210c2ae81a5c5329c94dc733026e7558fdccbe85bc76eba28e29168142f",
"contents": "{ ... Swagger spec ... }",
"created_at": 1611651060,
"id": "60c30ff5-e45c-4a79-94b1-aa07bb674fea",
"path": "specs/httpbin.json"
}