> Pretty print by default is one of those small things but makes your API that much easier to use. It makes it easy for customers who are debugging to easily read data and pleasant to use.
A pretty print option should be available, but the extra whitespace adds to the content size, which is obviously a bad thing when you have any real volume. As the primary consumer of a production API is not a person, pretty print should not be the default.
> Do not return total counts or loop through entire databases to get the large count.
The data that is available to consumers of an API should be based on actual use cases, and there is often a reasonable need for a consumer to have a total count. If there are performance implications associated with generating this, which won't always be the case, it's better to address those than leave the consumers of the API without the data they need.
Regarding your total count comment, thats what I thought and I completely agree. More often than not the extra performance hit is worth it for a better 'consumer experience'.
There's still no reason to add additional whitespace to a response that isn't going to be consumed by a human.
Also, it's worth pointing out that not all of your API consumers will necessarily support compression. The best practice is to use an Accept-Encoding header to allow the consumer to explicitly request a compressed response. This ensures that you can still serve uncompressed responses where necessary.
>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
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.
A pretty print option should be available, but the extra whitespace adds to the content size, which is obviously a bad thing when you have any real volume. As the primary consumer of a production API is not a person, pretty print should not be the default.
> Do not return total counts or loop through entire databases to get the large count.
The data that is available to consumers of an API should be based on actual use cases, and there is often a reasonable need for a consumer to have a total count. If there are performance implications associated with generating this, which won't always be the case, it's better to address those than leave the consumers of the API without the data they need.