mhoppa/deprecation_list.md

## deprecation_list.md

      
    Raw
  

              deprecation_list.md
            
          
    Deprecation routes


Deprecation routes

Approach
Deprecation Route Candidates

Routes that duplicate existing functionality
Routes to be deprecated and replaced
Routes to be deprecated with no direct replacement


Approach


Deprecated routes do not need to be rewritten from Perl to Go
Deprecated routes will still be available in 1.x but will not be available in 2.x
Deprecated routes will be marked as such in the documentation and will return a deprecation notice in the response

Deprecation Route Candidates

Routes that duplicate existing functionality


Route
Verbs
Existing Route support


asns/{id}
GET
Use asns route with query parameter id


cachegroups/trimmed

Use cachegroups route as trimmed is just a subset of the data returned from that endpoint


cachegroups/{id}/unassigned_parameters

Use cachegroupparameters route with query parameter cachegroup and diff that to parameters response


cachegroups/{id}
GET
Use cachegroups route with query parameter id


cdns/name/{name}
GET
Use cdns route with query parameter name


cdns/{id}
GET
Use cdns route with query parameter id


cdns/{name}/federations/{id}
GET
Use cdns/{name}/federations route with query parameter id


deliveryservice_matches

Use deliveryservices_regexes route as deliveryservice_matches is just a subset of its return data


deliveryservices/hostname/{{host name}}/sskeys

Use deliveryservices/xmlId/{{XMLID}}/sslkeys and filter the results via the hostname returned on array item


deliveryservices/{dsid}/regexes/{regexid}
GET
Use deliveryservices/{dsid}/regexes route with query parameter id


deliveryservices/{id}/unassigned_servers

Use either deliveryservices/{id}/servers route and diff that with servers or even better use deliveryservices/{id}/servers/eligible/


deliveryservices/{id}
GET
Use deliveryservices route with query parameter id


divisions/{id}
GET
Use divisions route with query parameter id


keys/ping

Use riak/ping route as it does the same thing and has the same backing logic


logs/{days}/days

Use logs route with query parameter days


parameters/profile/{name}

Use profiles/name/{name}/parameters route instead as same response is returned


parameters/{id}
GET
Use parameters route with query parameter id


phys_locations/trimmed

Use phys_locations route as trimmed is just a subset of the data returned from that endpoint


phys_locations/{id}
GET
Use phys_locations route with query parameter id


profiles/trimmed

Use profiles route as trimmed is just a subset of the data returned from that endpoint


profiles/{id}/unassigned_parameters

Use profiles/{id}/parameters route and diff that with parameters


profiles/{id}
GET
Use profiles route with query parameter id


regions/name/{name}
GET
Use regions route with query parameter name


regions/{id}
DELETE
Use regions route with query parameter id


regions/{id}
GET
Use regions route with query parameter id


servers/hostname/{hostName}/details

Use servers/details route with query parameter hostName


servers/status

Use servers route and do the counting client side. NOTE need to look into TP work to support this


servers/{id}
GET
Use servers route with query parameter id


statuses/{id}
GET
Use statuses route with query parameter id


steering/{deliveryservice}/targets/{target}
GET
Use steering/{deliveryservice}/targets route with query parameter target


tenants/{id}
GET
Use tenants route with query parameter id


types/{id}
GET
Use types route with query parameter id


user/{id}/deliveryservices/available

User delivery service associations provide no value in current system


users/{id}/deliveryservices

User delivery service associations provide no value in current system


Routes to be deprecated and replaced

Work to do in replacement


Route(s)
Replacement Path(s)
Reasoning


cdns/name/{{name}}/dnsseckeys/delete
cdns/name/{{name}}/dnsseckeys
The HTTP verb should not be apart of the route and a DELETE should not be a GET request


cdns/{{ID}}/snapshot & snapshot/{{CDN}}
snapshot
The two routes do the same thing besides specifying the CDN by name vs id. This could be combined into using the same route and specifying the identifier via query parameters.


deliveryservice_server/{{DS ID}}/{{Server ID}}
deliveryserviceserver/{{DS ID}}/{{Server ID}}
We already used the base route deliveryserviceserver for deliveryservice server association, should change this to maintain consistentency.


deliveryservices/xmlId/{{XML ID}}/sslkeys/delete
deliveryservices/xmlId/{{XML ID}}/sslkeys
The HTTP verb should not be apart of the route and a DELETE should not be a GET request


riak/bucket/{{bucket}}/key/{{key}}/values
vault/bucket/{{bucket}}/key/{{key}}/values
Get rid of riak verbiage in our routing naming as it is an implementation detail of traffic vault


riak/ping
vault/ping
Get rid of riak verbiage in our routing naming it is an implementation detail of traffic vault


servers/checks
servercheck
We represent server checks on two different paths servercheck & servers/checks. This is just cleaning them up so they are on the same path.


to_extensions
servercheck/extensions & plugins
to_extensions used to support CONFIG_EXTENSIONS, STATISTIC_EXTENSION and CHECK_EXTENSIONS in the Perl implementation but since in Go TO config,stat extensions were superseded by the plugin system the rewrite pulled just check extensions and configured plugins. This can be cleaned up to be more clear to the users of the API what they are interacting with by splitting them up.


Routes to be deprecated with no direct replacement


Route
Reasoning


/cdn/metric_types
Currently returns 501 in 1.x and provides no value


If VERBS is left blank that means route will be deprecated in whole
Route	Verbs	Existing Route support
`asns/{id}`	GET	Use `asns` route with query parameter `id`
`cachegroups/trimmed`		Use `cachegroups` route as trimmed is just a subset of the data returned from that endpoint
`cachegroups/{id}/unassigned_parameters`		Use `cachegroupparameters` route with query parameter `cachegroup` and diff that to `parameters` response
`cachegroups/{id}`	GET	Use `cachegroups` route with query parameter `id`
`cdns/name/{name}`	GET	Use `cdns` route with query parameter `name`
`cdns/{id}`	GET	Use `cdns` route with query parameter `id`
`cdns/{name}/federations/{id}`	GET	Use `cdns/{name}/federations` route with query parameter `id`
`deliveryservice_matches`		Use `deliveryservices_regexes` route as `deliveryservice_matches` is just a subset of its return data
`deliveryservices/hostname/{{host name}}/sskeys`		Use `deliveryservices/xmlId/{{XMLID}}/sslkeys` and filter the results via the `hostname` returned on array item
`deliveryservices/{dsid}/regexes/{regexid}`	GET	Use `deliveryservices/{dsid}/regexes` route with query parameter `id`
`deliveryservices/{id}/unassigned_servers`		Use either `deliveryservices/{id}/servers` route and diff that with `servers` or even better use `deliveryservices/{id}/servers/eligible/`
`deliveryservices/{id}`	GET	Use `deliveryservices` route with query parameter `id`
`divisions/{id}`	GET	Use `divisions` route with query parameter `id`
`keys/ping`		Use `riak/ping` route as it does the same thing and has the same backing logic
`logs/{days}/days`		Use `logs` route with query parameter `days`
`parameters/profile/{name}`		Use `profiles/name/{name}/parameters` route instead as same response is returned
`parameters/{id}`	GET	Use `parameters` route with query parameter `id`
`phys_locations/trimmed`		Use `phys_locations` route as trimmed is just a subset of the data returned from that endpoint
`phys_locations/{id}`	GET	Use `phys_locations` route with query parameter `id`
`profiles/trimmed`		Use `profiles` route as trimmed is just a subset of the data returned from that endpoint
`profiles/{id}/unassigned_parameters`		Use `profiles/{id}/parameters` route and diff that with `parameters`
`profiles/{id}`	GET	Use `profiles` route with query parameter `id`
`regions/name/{name}`	GET	Use `regions` route with query parameter `name`
`regions/{id}`	DELETE	Use `regions` route with query parameter `id`
`regions/{id}`	GET	Use `regions` route with query parameter `id`
`servers/hostname/{hostName}/details`		Use `servers/details` route with query parameter `hostName`
`servers/status`		Use `servers` route and do the counting client side. NOTE need to look into TP work to support this
`servers/{id}`	GET	Use `servers` route with query parameter `id`
`statuses/{id}`	GET	Use `statuses` route with query parameter `id`
`steering/{deliveryservice}/targets/{target}`	GET	Use `steering/{deliveryservice}/targets` route with query parameter `target`
`tenants/{id}`	GET	Use `tenants` route with query parameter `id`
`types/{id}`	GET	Use `types` route with query parameter `id`
`user/{id}/deliveryservices/available`		User delivery service associations provide no value in current system
`users/{id}/deliveryservices`		User delivery service associations provide no value in current system
Route(s)	Replacement Path(s)	Reasoning
`cdns/name/{{name}}/dnsseckeys/delete`	`cdns/name/{{name}}/dnsseckeys`	The HTTP verb should not be apart of the route and a `DELETE` should not be a `GET` request
`cdns/{{ID}}/snapshot` & `snapshot/{{CDN}}`	`snapshot`	The two routes do the same thing besides specifying the `CDN` by name vs id. This could be combined into using the same route and specifying the identifier via query parameters.
`deliveryservice_server/{{DS ID}}/{{Server ID}}`	`deliveryserviceserver/{{DS ID}}/{{Server ID}}`	We already used the base route `deliveryserviceserver` for deliveryservice server association, should change this to maintain consistentency.
`deliveryservices/xmlId/{{XML ID}}/sslkeys/delete`	`deliveryservices/xmlId/{{XML ID}}/sslkeys`	The HTTP verb should not be apart of the route and a `DELETE` should not be a `GET` request
`riak/bucket/{{bucket}}/key/{{key}}/values`	`vault/bucket/{{bucket}}/key/{{key}}/values`	Get rid of `riak` verbiage in our routing naming as it is an implementation detail of traffic vault
`riak/ping`	`vault/ping`	Get rid of `riak` verbiage in our routing naming it is an implementation detail of traffic vault
`servers/checks`	`servercheck`	We represent server checks on two different paths `servercheck` & `servers/checks`. This is just cleaning them up so they are on the same path.
`to_extensions`	`servercheck/extensions` & `plugins`	`to_extensions` used to support CONFIG_EXTENSIONS, STATISTIC_EXTENSION and CHECK_EXTENSIONS in the Perl implementation but since in Go TO config,stat extensions were superseded by the plugin system the rewrite pulled just check extensions and configured plugins. This can be cleaned up to be more clear to the users of the API what they are interacting with by splitting them up.