[
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)
