Change in the way Endpoints return Content-Type

3 minute read

API Endpoints always return application/json, irrespective of what is set by the HTTP Response flow-node, or what is defined in the Swagger produces.

This behavior has been deprecated since the API Builder - Tokyo release.

Beginning with the Tokyo release, if the flow defines a Content-Type header in the HTTP Response Headers, then the header will always be used. If the Content-Type header is not set in HTTP Response Headers, then the Content-Type is derived according to the type of response body. If the response body is a Buffer, then the Content-Type is “application/octet-stream”. For all other types, then the Content-Type the body is encoded as a JSON string and the Content-Type is “application/json”.

This will be the default behavior for all new services.

Why are we deprecating this feature

It is a significant limitation if API Endpoints cannot return any Content-Type, not just “application/json”.

How does this impact my service

This is now the default behavior for all new services. Any existing services will continue to work as they previously did, though it is strongly recommended you enable the new behavior on existing services. The following examples show the previous behavior when making a HTTP request to an API Builder endpoint.

Previous behavior

Body value Body type Flow Set HTTP Response Headers HTTP Response Content-Type HTTP Response Body
Buffer.from('AAECAwQ=', 'base64') Buffer { “content-type”: “image/png” } application/json { "type":"Buffer","data":[0,1,2,3,4] }
“banana” string { “content-type”: “image/png” } application/json "banana"
1234 number { “content-type”: “image/png” } application/json 1234
{ "test":"data" } Object { “content-type”: “image/png” } application/json { "test":"data" }
Buffer.from('AAECAwQ=', 'base64') Buffer application/json { "type":"Buffer","data":[0,1,2,3,4] }
“banana” string application/json "banana"
1234 number application/json 1234
{ "test":"data" } Object application/json { "test":"data" }

New behavior (enableOverrideEndpointContentType flag enabled)

Body value Body type Flow Set HTTP Response Headers HTTP Response Content-Type HTTP Response Body
Buffer.from('AAECAwQ=', 'base64') Buffer { “content-type”: “image/png” } image/png [0x0, 0x1, 0x2, 0x3, 0x4]
“banana” string { “content-type”: “image/png” } image/png "banana"
1234 number { “content-type”: “image/png” } image/png 1234
{ "test":"data" } Object { “content-type”: “image/png” } image/png { "test":"data" }
Buffer.from('AAECAwQ=', 'base64') Buffer applicaton/octet-stream [0x0, 0x1, 0x2, 0x3, 0x4]
“banana” string application/json "banana"
1234 number application/json 1234
{ "test":"data" } Object application/json { "test":"data" }

Upgrading existing services

This only effects services that are using API endpoints (e.g. endpoints/Greet.json) and that have flows that currently explicitly set the Content-Type HTTP Response Header (to no effect), or currently return a body that is a Buffer. Flows that return an Object will continue to work as before (i.e. the Content-Type will be “application/json”).

It is strongly recommended you upgrade API Builder to the latest version as well any data connectors you may have in your stack. This feature requires a minimum of:

  • API Builder - Tokyo

After upgrading, the enableOverrideEndpointContentType feature will not be active until you enable it. To enable it, add the following setting to your conf/default.js file:

// Service configuration
{
  flags: {
    enableOverrideEndpointContentType: true
  }
}

For more detailed information on the configuration options, see Project configuration.

Once enabled, review your service to ensure that you have no logic in your flows or APIs that depends on the deprecated behavior.

Last modified August 26, 2022: Created release schedule (#101) (712a2f1)