Robert Butts created TC-316:
-------------------------------

             Summary: 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


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.3.15#6346)

Reply via email to