Well, my point is that the `$version` there was available in 1.1, and the go functionality is only available under 1.4. I'm good with leaving it at that and just not allowing DNSSEC keys refresh in api versions under 1.4, but I want to be sure that's what you're saying.
On Mon, Aug 12, 2019 at 2:59 PM Robert Butts <[email protected]> wrote: > >GET /internal/api/$version/cdns/dnsseckeys/refresh > > Exactly the same as /api/1.4/cdns/dnsseckeys/refresh - needs backport > > to v1.1? > > It didn't exist in 1.1, new things require new minor versions. All of these > will have to go in a new minor version, currently 1.4+. We can only > "backport" code, not changes to API versions. > > Which is to say, `/internal/api/$version/cdns/dnsseckeys/refresh` is done, > and can be removed in the next major release. > > > On Mon, Aug 12, 2019 at 2:25 PM ocket 8888 <[email protected]> wrote: > > > Here's all the non-API endpoints that I could find that don't already > have > > equivalents under `/api/{{version}}/`: > > > > GET /health > > Returns a mapping of all profile names to an array of all of the > > parameters that have the ConfigFile 'rascal.properties' > > GET /healthfull > > Returns a mapping of server FQDNs to an array of all of the > parameters > > that have the ConfigFile 'rascal.properties' on said server's profile - > but > > ONLY if the server's profile's name starts with either "EDGE" or "MID". > > GET /health/{{CDN name}} > > Gets all of the servers within the specified CDN, returns an object > > that contains all of the unique parameters with the ConfigFile > > "rascal-config.txt" coalesced with all of the parameters used by the > > arbitrary last encountered server with a profile name starting with > RASCAL, > > all of the Profiles that both use such a parameter and start with either > > "MID" or "EDGE", and finally all of the Profiles that have names starting > > with "CCR" as well as all of the Delivery Services that use the last one > of > > those profiles encountered as well as specifically their global max MBPS > > and TPS. > > GET /internal/api/$version/cdns/dnsseckeys/refresh > > Exactly the same as /api/1.4/cdns/dnsseckeys/refresh - needs backport > > to v1.1? > > GET /internal/daily_summary > > For each CDN with at least one server that has a type that has a name > > beginning with "EDGE", gets the latest and maximum data transfer rate in > > Gb/s for the past day, as well as the total amount of data served in PB > for > > the past day. All of this comes from Influx, and I'm just inferring that > > the data is "daily" from the name of the table and endpoint. I don't see > > any query restrictions that actually enforce that. > > GET /internal/api/$version/federations > > Gets a list of all federation mappings (optionally restricted to only > > those within the CDN named by the "cdnName" query parameter when it is > > present) and the associated XMLIDs, types, and IP addresses for each. > > GET /update/{{hostname}} > > Retrieves a list of objects that contain the hostname, upd_pending > > status, reval_pending status, id, status, parent_pending status, and > > parent_reval_pending for all servers that have a hostname that matches > > `hostname` (or all servers if the `hostname` path parameter is the > special > > value `all`). > > POST /update/{hostname}} > > Accepts a payload setting the values of upd_pending, reval_pending > and > > status for a given server with the hostname `hostname`. > > > > which, if any, of these does anybody feel strongly about pulling into the > > proper API? > > >
