Home → Questions →

Gzip compression on API Requests

• Edit

Craig Willis

22 Jun, 2016 09:36 AM

Is GZIP compression supported on API Requests? We've noticed that some of our requests have started hitting 20kb, and we are little worried that as the number of invoices grow, this will just keep getting larger.

We're sending Accept-Encoding: gzip,deflate on our requests, but it doesn't appear to be supported.

1. 1 Posted by Craig Willis on 22 Jun, 2016 09:43 AM

   

   another option might be a way to just get back less data? When I call Add-Item-Quantity, I don't really care about the response, I'm just checking if it passed or failed, I don't actually need the full customer data returning.

   It wouldn't be too much of an issue, but these requests are taking 0.7 of a second on our dev environment, which feels a bit slow, considering getting the full customer data takes 0.5 seconds.

   • Edit

2. Support Staff 2 Posted by Marc Guyer on 22 Jun, 2016 01:27 PM

   

   Hi Craig -- Thanks for bringing this up. Our web heads are already configured to compress the usual suspects: text/html, text/css, text/xml, application/javascript, and some others. Our app serves xml responses as content-type application/xml which is not in the default settings. Customized config to deflate that mime type (and some others) never got added. It's been on the back of our minds for some time. I'll bring it up in our next all team meeting for discussion. The primary question is whether or not we need to be careful of breaking existing users' integrations and perhaps notifying them of the config change. I don't think that's necessary off the top of my head since all http clients should be able handle it. However, there's the possibility of systems in the wild that are relying on uncompressed responses despite the content-encoding header in the response. It's a long shot but something to talk about nonetheless.

   Regarding your "less data" comment... That, too, is something we've been working on. It's a project on the back burner currently but much of the work is already done. In short, the new API will be JSON responses and the content of those responses is being refactored to be more compact and sustainable. We're working on additional funding and dev bandwidth to give that project the proper focus. Once complete, it should be relatively trivial to drop in a new client lib to retrofit existing integrations.

   We'll update you here on both items when we have more information.

   • Edit

3. Support Staff 3 Posted by Marc Guyer on 07 Jul, 2016 07:49 PM

   

   Hi Craig -- Thanks again for raising this flag. We went ahead and started gzipping responses with mime types application/xml and application/json. How's your integration coming along?

   • Edit

4. 4 Posted by Craig Willis on 12 Sep, 2016 08:11 AM

   

   Mark,

   Integration is going well, and I can see the gzipping is working on the responses without issue, thanks for that.

   It's certainly making a difference, about a 85% reduction in response size.

   Thanks.

   Craig Willis

   • Edit

5. Support Staff 5 Posted by Marc Guyer on 12 Sep, 2016 03:06 PM

   

   Thanks for confirming, Craig. Let us know if we can help further.

   • Edit

6. Marc Guyer closed this discussion on 12 Sep, 2016 03:06 PM.