6

We have a custom REST API that doesn't seem to support gzip compression.

curl https://mobileteamdeploycommunity.force.com/taroworks/services/data/v33.0/ -H 'Authorization: Bearer xxxxxxxxxxxxxxxxxx' -H 'Accept-Encoding: gzip' -v

Which uses the Salesforce API seems to work fine and compresses that data. But

curl https://mobileteamdeploycommunity.force.com/taroworks/services/apexrest/performance/ -H 'Authorization: Bearer xxxxxxxxxx' -H 'Accept-Encoding: gzip'  -v &> performance_with_gzip

Which uses our custom REST API doesn't compress and we get the JSON result uncompressed.

Is there a way to make compression work in the second case?

Improve this question
6
  • One oddity in the documentation for Force.com REST API Developer's Guide - Using Compression "The REST API is not required to compress the response even if you have specified Accept-Encoding, but it normally does. If the REST API compresses the response, it also specifies a Content-Encoding header." Is there something odd about what the REST service is returning that might prevent compression?
    – Daniel Ballinger
    Commented Apr 16, 2015 at 0:05
  • Yeah, I saw that in the docs. Wish they said under what circumstances Salesforce compresses. The response is just straight JSON that could benefit quite a bit from compression. Can't think of a reason why it would be compressed.
    – Dror
    Commented Apr 16, 2015 at 0:24
  • What headers do you see in the response? I did a quick HTTP GET test against a very basic @RestResource that just returns a short string. It came back with Content-Encoding: gzip, Content-Type: application/json;charset=UTF-8. So it would appear to be compressed.
    – Daniel Ballinger
    Commented Apr 16, 2015 at 1:03
  • Interesting. So the Salesforce REST returns: < Content-Type: application/json;charset=UTF-8 Content-Encoding: gzip Vary: Accept-Encoding. Our REST calls return: Content-Type: application/octetstream. I suspect that your string wasn't compressed because it was too short. Compression is not worthwhile if the string is short. But I need to see if I can replicate getting Content-Encoding: gzip.
    – Dror
    Commented Apr 16, 2015 at 1:59
  • I was using Postman in Chrome to test with. Looking at the Network tab in the developer tools I noticed it would send the Accept-Encoding header regardless. Your 'Content-Type: application/octetstream' looks odd to me. I wouldn't have expected the Content-Type to change based on the compression. You wouldn't be returning a Blob by any chance?
    – Daniel Ballinger
    Commented Apr 16, 2015 at 9:08

1 Answer 1

Reset to default
1

Created a simple test with the following code:

@RestResource(urlMapping='/testRest/*')
global with sharing class TestRest {

@HttpGet
global static List<sObject> doGet() {
    RestRequest req = RestContext.request;
    RestResponse res = RestContext.response;
    List<sObject> result = [SELECT id, ownerId, name from report];
    return result;
  }

}

Ran the curl command

curl https://na16.salesforce.com/services/apexrest/testRest -H 'Authorization: Bearer xxxxxxx' -H 'Accept-Encoding: gzip' -v > performance_with_gz ; cat performance_with_gz

Where xxxxxx is the token (see resources on how to get it) and the result headers were: < HTTP/1.1 200 OK < Date: Thu, 16 Apr 2015 21:23:41 GMT < Set-Cookie: BrowserId=vOR1P_eXQxSIXNSlB05oxA;Path=/; Domain=.salesforce.com;Expires=Mon, 15-Jun-2015 21:23:41 GMT < Expires: Thu, 01 Jan 1970 00:00:00 GMT < Content-Type: application/json;charset=UTF-8 < Content-Encoding: gzip < Transfer-Encoding: chunked

and the content was indeed gzip encoded.

So Salesforce does indeed gzip compress custom REST APIs and it looks like the issue is on our side.

Resources:

http://www.oyecode.com/2014/07/try-any-salesforce-api-quickly-with.html http://www.oyecode.com/2014/08/start-building-your-own-rest-api-in.html https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_rest_code_sample_basic.htm

Improve this answer
1
  • The issue was that we were returning void from doGet() and setting the data in RestContext.response.responseBody, but didn't do response.addHeader('Content-Type', 'application/json'); Since the responseBody is a blob, As Daniel correctly guessed above, it returns Content-Type: application/octetstream.
    – Dror
    Commented Apr 22, 2015 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .