Content Filter Pattern for REST Service Fields Filtering
Content Filter Pattern for REST Service Fields Filtering
What if the service consumer doesn’t want all the fields all the time? They want to have the response filtered. Content Filter to the rescue!
Join the DZone community and get the full member experience.
Join For FreeAt some point, you may have a service that returns a lot of fields and related objects. What if the service consumer doesn’t want all the fields all the time? In other words, he/she would like to have the response filtered. Here comes the Content Filter to the rescue. After you read this article you will find some ideas about how to use it in your own scenarios. So let’s roll.
Content Filter
This is the opposite pattern to Enrchier Pattern – more about it you can find here. In this particular scenario, we want to simplify our response. Remove unnecessary information that the receiver doesn’t need.
As you can see in the diagram above, before filter we have a message with 3 elements and after the filter is applied we have only one element. The magic is happening in the black boxes called Content Filter. However, we as designers should know how this particular element works. So, how to define filter?
We may choose two ways of doing this:
- Positive filter – we specify what we would like to have in the response
- Negative filter – we specify what should be removed from the original payload
Filtering in Mule 4 Using DataWeave 2.2
In order to filter out some fields, we have DataWeave language. So for filtering purposes, we will use the Transform Message component. We can filter properties from objects and arrays. So let see how to do the positive and negative filtering in DW.
Negative Filtering
In DataWeave we have two operators – and –. The first one allows for removing a key-value pair by providing the key.
Okay, that way I can remove one field at a time. In order to remove two fields like in the example above I would need to do it in the following way:
%dw 2.0
output application/json
---
{
"id": "idy4234-2",
"title": "Meetup"
} - "id" - "title"
The double dash operator (–) allows providing keys array. In other words, each key present in the array will be removed from the supplied object.
In the example above we have provided an array with title and id keys. As a result of applying — operator, we got the empty object.
Positive Filtering
This is the opposite scenario in contrast to previously described negative filtering. This time we would like to define which properties should stay, not mentioned ones should be removed from the final outcome.
We don’t have a similar operator to perform that action. filterObject function is the best match for that case. This function iterates over each key and applies lambda expression. If the condition is evaluated to true, include the field in the output. Otherwise, omit it.
Below you can see a code snippet showing how to do a positive filter. We instruct filterObject to include the key-value pair only if the key is present in the array – here “id”.
xxxxxxxxxx
%dw 2.0
output application/json
---
{
"id": "idy4234-2",
"title": "Meetup"
} filterObject ((value, key) -> ["id"] contains key as String)
Filter Fields in Your REST Service
I have looked for may publicly available services to see some good guidelines to do the filter. However, a lot of them are too complex or simple. Here what you can see, is some version in between. Below you can see a trait filter definition.
As you can see I have decided to introduce the default value *all indicating that all fields will be returned. To distinguish negative and positive filtering I have decided to introduce – (minus) prefix before fields to remove from the final response. Values are separated by the comma without any additional space.
Warning: We can’t mix the positive and negative filters. I have decided on this rule because it makes sense. Either we want to specify what should be returned or skipped.
Here is the link to the trait filterable. You can place it some common traits library or in specif API directly.
Use Trait in Your API Specification
In order to use an externally defined trait, you need to include it in the API specification. You will do this like in the snippet below:
xxxxxxxxxx
#%RAML 1.0
title: Consent Experience API
version: v1
baseUri: https://sfdc-consents.profit-online.pl/api/{version}/
mediaType: [ application/json ]
types:
consent: !include types/consent.raml
traits:
filterable: !include traits/filterable.raml
As you can see declared filterable trait in traits section. How to apply this to the resource?
You need to specify the array of traits using is, like in the second line on the snippet below.
xxxxxxxxxx
/consents:
is: [filterable]
get:
responses:
200:
body: consent[]
Example Usage
The first case is the call to retrieve all the fields
xxxxxxxxxx
GET /mongodb/sapi/consents HTTP/1.1
Host: ambassadorpatryk.com
or
xxxxxxxxxx
GET /mongodb/sapi/consents?filter=*all HTTP/1.1
Host: ambassadorpatryk.com
The second case is to retrieve only specified fields:
xxxxxxxxxx
GET /mongodb/sapi/consents?filter=id,name,title HTTP/1.1
Host: ambassadorpatryk.com
The third case is to retrieve the response without the specified fields:
xxxxxxxxxx
GET /mongodb/sapi/consents?filter=-details,-id HTTP/1.1
Host: ambassadorpatryk.com
Summary
I think that the presented solution for filtering fields gives some flexibility but isn’t overcomplicated. In many publicly, available APIs providers give the possibility to decide which fields are expected at the response. In the next article, I will introduce my filter DataWeave module. Stay tuned!
If you have any other ideas on how to introduce filtering fill free to share it. Let’s learn from each other.
Have a great day!
More my content you can find on my personal blog, dedicated to MuleSoft Integration.
Published at DZone with permission of Patryk Bandurski , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}