[jira] [Updated] (TC-316) Create Traffic Monitor 2.0 API Version Two

["Ryan Durfey (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TC-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Durfey updated TC-316:
---------------------------
    Labels: api_endpoints  (was: )

Consider this in the new version https://cwiki.apache.org/confluence/display/TC/API+Guidelines

> Create Traffic Monitor 2.0 API Version Two
> ------------------------------------------
>
>                 Key: TC-316
>                 URL: https://issues.apache.org/jira/browse/TC-316
>             Project: Traffic Control
>          Issue Type: New Feature
>          Components: Traffic Monitor (golang)
>            Reporter: Robert Butts
>            Priority: Minor
>              Labels: api_endpoints
>
> Traffic Monitor 2.0 must implement the current API from 1.0, so existing integrations (Traffic Router, Traffic Stats) will work.
> But we'd like to make a more modern API, which other apps can later be moved to.
> Proposed goals:
>     More well-known paths. Current path is /publish/X, suggest /api/X.
>     Consider versioning, e.g. /api/v2/. Also consider not versioning, since the 1.0 API is not at /api/. it looks like a lot of products seem to get it right the second time. There seem to be a lot of "version 2" APIs out there (Stripe, Slack). Maybe we should not version and guess this will be final, for its data. Alternatively, we could version, /api/v2/, and also link /api/ to the current version. Then, if we feel there won't be a version 3 after some time, /api/v2/ could be deprecated.
>     More structure. For example. the current API for Delivery Service stats returns {"deliveryService": {"adcolony": {"location.us-al-malt.error-string": {"value": "foo"}, "location.us-al-malt.in_bytes": {"value":24} ...
>     This could be changed to
>     {"deliveryService": {"adcolony": {"location": {"us-al-malt": {"error-string": {"value": "foo"}, "in_bytes": {"value": 24} ...
>     To reduce duplicate text, make messages smaller, and make the message easier to read for both humans and computers, and in a structure more suitable for representation in the code. For example, "location.us-al-malt.in_bytes" requires custom string parsing to isolate each part, whereas putting each part in JSON keys allows standard JSON library parsing.
>     Add CSV responses. CSV is significantly faster to parse, and with the size of our data, it might make a relevant difference in application performance. We should consider both CSV for existing endpoints requested with an Accept: text/csv header, and new endpoints with smaller and two-dimensional data.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)