>There's still no reason to add additional whitespace to a response that isn't going to be consumed by a human.

The point is if you don't know which requests are going to be consumed by a human, and which are being consumed by eyeballs of developers testing your API, it's a legitimate design tradeoff to consider printing your responses in a human readable way. (And yes, "?pretty_print=1" is another option, but of course this has its own set of obvious tradeoffs.)

You seem to think that a <1% hit on (uncompressed) response size doesn't outweigh the benefits of such a design choice. But the problem is you're not expressing this as an opinion but as a fact. There are plenty of scenarios (I'd argue the majority) where a tiny increase in the % of bytes you transfer is worth making it so developers can easily debug your API. Particularly when you are an API-providing startup with a few people and minimizing support-side touch points is crucial to scaling.

What I wrote is based on a) best practice, b) the understanding that the vast majority of APIs are, in production, consumed by applications, not humans, and c) the knowledge that, in high-volume production environments, small inefficiencies can add up to larger inefficiencies.

Finally, I don't know where you came up with your 1% figure but I just ran a test on an API I use and the uncompressed pretty printed response was 24% larger than the uncompressed non-pretty printed response because of all the whitespace. I'd challenge you to find a scenario under which a pretty printed response of reasonable size is only 1% larger than its non-pretty printed counterpart.

To add more data to this discussion, I've been playing with the GitHub Issues API recently, which pretty-prints by default. I grabbed the last hundred open issues from the Mozilla Persona repo, and found

        == Uncompressed ==
  Pretty Printed: 312,556 bytes
        Minified: 272,604 bytes
                  -------------
           Delta:  39,952 bytes (+14.66%)

Not as bad as a 24% hit, but that's all moot because gfodor very explicitly discussed using gzip when pretty-printing. Let's see what happens there:

           == Gzipped ==
  Pretty Printed:  41,748 bytes
        Minified:  40,648 bytes
                  -------------
           Delta:    1,100 bytes (+2.71%)

Not as good as the original claim of <1%, but still pretty darn negligible.

Data derived from this API endpoint: https://api.github.com/repos/mozilla/browserid/issues?per_pa...

Thanks. My <1% claim was ill-founded, I was assuming the use of tabs and trailing braces to minimize single-character lines so a little arithmetic in my head pointed to a small relative cost. But out of the box pretty printing does not try to minimize whitespace characters like this. Seems like it could be a worthy hack.