### **1. Transform a Request Body to Maintain Backwards Compatibility**

Imagine that we've shipped an API to a handful of early access customers, and they've integrated it and are using the API in production. Then disaster strikes—we realize that we've made a typo in one of the field names! We [accidentally](https://stackoverflow.com/questions/3087626/was-the-misspelling-of-the-http-field-name-referer-intentional)accidentally named a field referer rather than referrer.

How could we fix this without impacting our early access customers? jq to the rescue!

By assigning a field using = and the del() function, we can create a new field containing the value of referer and delete the old key. This has the effect of renaming a key in the request body:

.referrer = .referer | del(.referer)

Although this program contains spaces, there is no need to encode the request:

curl -X POST http://localhost:8001/services/Demo/plugins \
    --data "name=jq"  \
    --data "config.request_jq_program=.referrer = .referer | del(.referer)"

### **2. Delete Sensitive Information From a Response**

The next scenario is a backend team built an API for us, but they've left in some sensitive information that we don't want to share with customers. We asked for it to be removed, but the API should have been launched last week, and we can't wait another two weeks for the team to make the changes.

We want to launch today but only show the standard pricing field:

{
  "useful": "information",
  "pricing": {
    "base": 1000,
    "partner": 1100,
    "standard": 1200
  }
}

How do we remove these sensitive fields from the response dynamically? Once again,jq to the rescue! There are a couple of ways to achieve what we want to do. The first is to call del() multiple times:

del(.pricing.base) | del(.pricing.partner)

This works but isn't the most efficient way to accomplish our goal. Instead, we can step in to pricing then delete multiple keys within that object:

del(.pricing | .base,.partner)

Once we apply this transform using response_jq_program, we'll get the following response body:

{
  "useful": "information",
  "pricing": {
    "standard": 1200
  }
}

The data we wanted to remove is gone, and we can ship our new API today!

### **3. Convert a JSON Response to CSV**

Imagine that we built a lovely JSON API for our customers that works great, but then one of our valuable customers comes back to us saying, "But it doesn't work in my spreadsheets! Can you provide the data as CSV too?"

We don't want to invest more development time for just one customer, but we want to make them happy. How do we tackle it? That's right! We can use jq.

In this example, we'll be returning a list of sessions presented at [Kong Summit 2021](https://konghq.com/kong-summit/2021-videos)Kong Summit 2021 through an API. Here's a sample of what the API looks like:

[
  {
    "title": "Opening Keynote: Developing the Connected World",
    "description": "Join Kong's co-founders, along with special guests, live as they explore cloud connectivity in today's digital world and what that means for modern, connected enterprises. They will also unveil the latest in Kong products and technology -- be the first to see a sneak peek of Kong's newest features and updates.",
    "presenters": [
      "Augusto Marietti",
      "Marco Palladino",
      "Reza Shafii"
    ],
    "date": "2021-09-28"
  }
]

This is a slightly more complicated processing pipeline than the examples shown so far, so we'll build it up section by section. The first row we need to output is a list of field names. We can do this by fetching the keys from the first entry in the array:

.[0] | keys_unsorted as $keys

Next, we need to process the payload to remove any complex data structures as they can't be represented in a CSV. In our API, the only complex data is the list of presenters, which we'll convert to a string by mapping over each entry and joining the list with a comma:

map(.presenters = (.presenters | join(", ")))

Now that the data only contains strings, we need to remove all key names. We can do that using map and $keys. It looks odd, but what we're saying is "add a row containing all of the available keys, then return a list of values, one for each available key":

([$keys] + map([.[ $keys[] ]]))

At this point, our data looks like the following:

[
  [
    "title",
    "description",
    "presenters",
    "date"
  ],
  [
      "Opening Keynote: Developing the Connected World",
      "Join Kong's co-founders, along with special guests, live as they explore cloud connectivity in today's digital world and what that means for modern, connected enterprises. They will also unveil the latest in Kong products and technology -- be the first to see a sneak peek of Kong's newest features and updates.",
      "Augusto Marietti, Marco Palladino, Reza Shafii",
      "2021-09-28"
  ]
]

The final thing to do is to remove the wrapper array and convert it to CSV:

[] | @csv

Putting it all together, we get the following:

(.[0] | keys_unsorted) as $keys | map(.presenters = (.presenters | join(", "))) | ([$keys] + map([.[ $keys[] ]])) [] | @csv

Which returns a CSV response:

"title","description","presenters","date"
"Opening Keynote: Developing the Connected World","Join Kong's co-founders, along with special guests, live as they explore cloud connectivity in today's digital world and what that means for modern, connected enterprises. They will also unveil the latest in Kong products and technology -- be the first to see a sneak peek of Kong's newest features and updates.","Augusto Marietti, Marco Palladino, Reza Shafii","2021-09-28"

We're almost there, but not quite! We don't want to return a CSV payload to everyone, so we need to register a new route using Kong. We expect consumers to send an Accept: text/csv header to get the CSV response. Here's the configuration I used to create this route:

Finally, we have to enable the jq plugin on our new route. We can use the jq expression above as config.request_jq_program like normal, but we need a few other configuration options when working with CSV. The default options for jq are to compress the output and escape any quotes. As we're returning CSV data, we don't want this to happen, so we need to set config.response_jq_program_options.compact_output to false and config.response_jq_program_options.raw_output to true.

Once we set those configuration options, we're all good to go! We now have an endpoint that returns CSV data for our high-profile customer with zero development effort.

### **4. Convert Celsius to Fahrenheit**

One final example before you go and try the jq plugin out yourself.

Imagine this—we've got a wildly successful greenhouse temperature monitoring product that's working really well in the EU, and we want to launch the product in the US. We're unsure if it will do as well, so we do some initial user testing. Feedback is positive except for one thing—they'd prefer to see the temperature in Fahrenheit rather than Celsius.

As it's a small batch of testers that we're very hands on with, we decide to convert on the fly using jq to validate our hypothesis rather than getting our engineering team to build the functionality. An API that returns data in the following format powers our application:

{
  "current": {
    "units": "celsius",
    "temperature": 27.3,
    "time": 1636554556
  },
  "previous": {
    "units": "celsius",
    "temperature": 27.7,
    "time": 1636550956
  }
}

Our UI uses the units and temperature from the API, so we need to rewrite those two fields in both current and previous to be in Fahrenheit. Once again, we'll be using map to apply to each entry in the response.

map(.temperature |= . * 9/5 + 32 | .units="fahrenheit")

This will convert the temperature and units values in every key in the returned object. This works for the simple use case above, but what if our response was a little more complex? What if it also contained a location and an account ID?

{
  "current": {
    "units": "celsius",
    "temperature": 27.3,
    "time": 1636554556
  },
  "previous": {
    "units": "celsius",
    "temperature": 27.7,
    "time": 1636550956
  },
  "_meta": {
    "location": "London, UK",
    "account_id": "193749"
  }
}

Using the jq expression above would result in an error:

jq: error (at <stdin>:16): null (null) and number (9) cannot be multiplied

Thankfully, jq also supports if statements that allow us to run our transform conditionally. Here's a transformation that checks that the units key has a value of celsius before trying to convert to Fahrenheit. If it doesn't equal celsius then it returns the original object:

map(if (.units == "celsius") then .temperature |= . * 9/5 + 32 | .units="fahrenheit" else . end)

Once we apply this jq plugin to a specific route that we're using in our beta testing, we can go ahead and test with US customers once again - this time with the units they're familiar with.

## Give It a Go!

That's all we've got time for today, but hopefully, it's given you an idea of how the jq plugin works. You can learn about the available plugin options on Kong's[ plugin hub](https://docs.konghq.com/hub/kong-inc/jq/) plugin hub or learn more about jq itself by reading the[ jq manual](https://stedolan.github.io/jq/manual/) jq manual.

We'd love to hear more about what you're doing with jq and Kong. You can tweet us at @thekonginc, and who knows, maybe we'll get together and do a jq themed episode of [Kong Builders](https://konghq.com/kong-builders/)Kong Builders.