Yes, that's what I'm saying. Putting it in 1.1 breaks SemVer. Yes, that means if someone upgrades Traffic Ops, they will also have to upgrade clients, after the non-API endpoint is removed. The non-API endpoint doesn't fall under the API "version promise" but it does fall under the "We won't delete things without deprecating in one major version" promise (without which, it would be impossible for users to upgrade).
>the `$version` there was available in 1.1 It was available in a TC version which happened to provide /api/1.1, but the endpoint itself wasn't available in /api/1.1, hence it falls under the "release version promise" not the "API version promise." > GET /internal/api/$version/cdns/dnsseckeys/refresh Ah, I think I see the confusion. We don't provide a version promise for "/internal/api/1.1/" routes. It's unfortunate they're named like that, but we've never provided any kind of "promise" for "/internal" routes (beyond the project deprecation/release version promise). We could vote to start providing that promise, but IMO we really shouldn't, it'd be a serious pain, and they're a terrible routing path we all want to go away. On Tue, Aug 13, 2019 at 9:58 AM ocket 8888 <[email protected]> wrote: > 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? > > > > > >
