logs api endpoint returning inconsistent json

[jmervine]

If you look at a logs result:

{
  "limit": 1,
  "next_page_key": "1403239656253",
  "page": 1,
  "records": [
    {
      "bytes": 1150,
      "cache_status": "HIT",
      "client_asn": "AS22773 Cox Communications Inc.",
      "client_city": "Irvine",
      "client_continent": "NA",
      "client_country": "US",
      "client_dma": "0",
      "client_ip": "98.189.223.98",
      "client_latitude": 33.7422981262207,
      "client_longitude": -117.76840209960938,
      "client_state": "CA",
      "company_id": 23761,
      "hostname": "cdn.mervine.net",
      "method": "GET",
      "origin_time": 0,
      "pop": "lax",
      "protocol": "HTTP/1.1",
      "query_string": "",
      "referer": "-",
      "scheme": "http",
      "status": 200,
      "time": "2014-06-20T04:47:36.253Z",
      "uri": "/bootstrap/favicon.ico",
      "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36",
      "zone_id": 164197
    }
  ],
  "request_time": 6
}

Note that it's missing code and data keys that the other endpoints have...

e.g. /account.json/address

{
  "code": 200,
  "data": {
    "address": {
      "city": "Los Angeles",
      "country": "US",
      "date_created": "0000-00-00 00:00:00",
      "date_updated": "2014-06-20 05:11:20",
      "id": "23337",
      "state": "CA",
      "street1": "go-20140619221114034",
      "street2": "1401986788489_3",
      "zip": "91604"
    }
  }
}

[jdorfman]

@jmervine good point. cc: @tdondich @bfields-maxcdn

[tdondich]

@jmervine In your experience with API's, which format would you prefer? We were hoping to get rid of the code and data levels in our v3 api rewrite.

[jmervine]

I don't think it matters too much, really. The code, data, error
abstraction is helpful for go-maxcdn, but certainly not required. It allows
for a simple generic response object, while enabling the consumer to parse
the data in a custom and abstracted way. Removing it though would result in
a cleaner response, as long as the following are met:

1. HTTP status code and status message are accurate and helpful.
2. On error, an error field is returned, something like '{ "error": {
   "type": "type message", "message": "error description" } }' as you return
   now.
3. Most importantly, they're consistent, which is the issue now. Start
   building out 'v3' under the new format, but don't release it until all
   endpoints are available, or call it 'alpha' ( /v3-alpha/... ) or or
   something.

J

On Fri, Jun 20, 2014 at 9:30 AM, tdondich notifications@github.com wrote:

@jmervine https://github.com/jmervine In your experience with API's,
which format would you prefer? We were hoping to get rid of the code and
data levels in our v3 api rewrite.

—
Reply to this email directly or view it on GitHub
#21 (comment).