ocket8888 commented on issue #3023: WIP Supported routes fetch
URL: https://github.com/apache/trafficcontrol/pull/3023#issuecomment-438438994
 
 
   An endpoint that lists the available versions must by necessity be outside 
the versioning it lists. Placing it under a versioned route will, first of all, 
cause the API definition of previous versions change, and secondly will replace 
the "N+1" problem with the "chicken and egg" problem. If I don't know what 
versions the API has, I'm forced to try `/api/1.0/api-routes` and when that 
404's I'm back where we are today. The `X-Server-Name` header tells me that I 
know I'm dealing with a version of Traffic Ops where re-implementation in Go 
has started, but beyond that it could be anywhere between experimental and 
present day. So an endpoint relaying communications options is totally useless 
if it's versioned.
   
   Rather than change the output to JSON, I'd prefer to just implement content 
negotiation. I still think the relationships and data being represented are too 
simple to use JSON by default, but if a client expects JSON they should send 
`Accept: application/json` and the endpoint should probably support that.
   
   I don't understand why not versioning the `api/` endpoint would in any way 
inhibit our ability to fix anything later. It should be as simple as adding
   ```rst
   .. versionchanged:: Traffic Ops 5.8
       Now conforms to RFC 99999
   ```
   to the docs. I know nothing else is versioned against Traffic Ops, but maybe 
that's just an exception we have to make, because like I said the `api/` 
endpoint by concept definition cannot be versioned with the rest of the API.
   
   FWIW all of this confusion would vanish if we tied the API version to the 
Traffic Ops version.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to