A tale of two RESTful API queries…
At the suggestion of +Will Norris, I updated this demo code for translating URLs to activity IDs to now use a filter. The following code highlights the differences:
< + '/activities/public?fields=items%2Fid%2Citems%2Furl&key=' + key --- > + '/activities/public?key=' + key
The only difference is the fields parameter that I had configured using the fields editor from the API explorer.
I didn’t realize how much less data would be used by the API calls but to illustrate the difference I created some screenshots.
An example of the activity feed from API calls without the filter:
An example of the activity feed from API calls with the filter:
Yeah, there’s a lot less data in the second screenshot, like 20x less data. Actually…
2.65 kb with the filter versus:
97.25 kb without the filter.
This is a difference of 36x. That’s crazy!
The key thing to look at in the results is the difference between each of the items. The content after the line > 0 : Object is the relevant difference, in the first example without the filter there are dozens of fields being returned of varying size, in the second example, only two fields that are relatively small are returned. I have clearly been wasting lots of bandwidth by not filtering my API calls.
After seeing the differences, I will definitely start thinking about filtering specific fields from API calls, it’s easy to do and actually makes the API call output easier to debug. In the grander scheme of things, filtering will save end user’s CPU cycles and bandwidth. If you really wanted to stretch this idea out completely, this means that less power would be used globally, less heat generated by computers, and less fossil fuels consumed for power… wait, this could reduce global warming!
OK, I got a little carried away there… the moral of the story is this, filter your API calls whenever you can.