[GitHub] [trafficcontrol] jhg03a commented on issue #2872: RFE: Add supported API versions API

[GitBox <gi...@apache.org>]

jhg03a commented on issue #2872:
URL: https://github.com/apache/trafficcontrol/issues/2872#issuecomment-1092322834

   In hindsight, I think diving into endpoint specifics over-complicates things.  A lot of concern with an unversioned API endpoint would be that like any endpoint the payload can change and thus break clients making requests (which is valid).  A simple list of strings with the version number is sufficient.  The promise being that the strings themselves once created are immutable until the day they're removed indicating that the version they represent is no longer available.  If other aspects such as supported, unsupported, deprecated wish to be conveyed they would be additional entries until the day they're removed (i.e. `['2.x','3.0.1','4.0','2.x deprecated','5.0 unstable <some kind of id> in case something cares which it shouldn't']` which eventually becomes `['3.0.1','4.0','5.0']` etc.).  It's not as great as something more structured or granular, but hopefully out of the simplicity we can avoid problems down the road needing to express things differently, thus breaking an unvers
 ioned api.  Any client should be able to query that and more gracefully degrade or internally downshift/upshift the instantiated client code version used because it knows the magic strings it was developed against to support.  As a bonus this unversioned enpoint serves as a runtime, code-based form of documentation as to what's available in a given release.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@trafficcontrol.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org