GET webhook response with filtering issue [SOLVED]

photon
Tags: #<Tag:0x00007fe222eb7c40>

#1

I am working in a Particle webhook which has a JSON that could have a lot of data and I plan to provide through query parameters the id of the correspondent array of data that I want to collect.

However, I’m having problems getting the correct mustache template/response template format correct.

I’ve been testing the URL giving the query parameters over postman and everything works good but when I try to add a filter to the query parameters, it simply looks like I am doing it in a wrong way.

I have three query parameters.

  • id
  • access_token
  • filter

Here’s an example from postman and the response. The number 14 is provided by me and it will be provided later by the Particle Photon.

and this is the example URL from my browser according to postman:

http://myapp.com/api/Sets?id
=1&access_token=<here_is_my_access_token>&filter={"where":{"workoutId":14}}

And this is my webhook setup:

And finally this is my Particle.publish() function defined:

char data[256];
int my_id = 1;
int my_workoutId = 14;
snprintf(data, sizeof(data), "{\"id\":%d, \"{\"where\":\"{\"workoutId\":%d}}\"}", my_id, my_workoutId);
Particle.publish("my_app", data, PRIVATE);

What I get from particle cloud is simply error 404 from the webpage:

So basically what I want is to figure it out is to know how to setup filters over the query parameters in particle webhooks to get the response that I want (Like the postman picture). This could benefit people that want to handle dynamic JSON data. Thanks!


#2

Why do you have leading double quotes before the opening curly braces?
You don’t have them in your postman JSON, so why add it then in your code?
Have a close look and compare the working and non-working strings and see :wink:

working
image
not working
image

BTW, the number of opening double quotes does not match the number of closing ones either.


#3

Hello @ScruffR,

Why do you have leading double quotes before the opening curly braces?
You don’t have them in your postman JSON, so why add it then in your code?

I was basically playing with the string looking for different outputs. So sorry for the typos in the last post.:sweat_smile:

I’ve fixed the query parameters from the webhook setup and my code:

from the webhook:

{
  "id": "{{{user_id}}}",
  "access_token": "xxx",
  "filter": "{\"where\":{\"workoutId\":{value_id}}}"
}

and my code is:

int my_id = 1;
int my_workoutId = 14;
String data = String::format("{\"id\":%d,\"filter\":{\"where\":{\"workoutId\":%d}}}", my_id, my_workoutId);
Particle.publish("workout_rest", data, PRIVATE);

But the problem remains, am I still missing something with my format setup in code or in the webhook response template setup?

I’ve found during testing that if I change the response template from this (Here gives me a 400 response error):

{
  "id": "{{{user_id}}}",
  "access_token": "xxx",
  "filter": "{\"where\":{\"workoutId\":{value_id}}}"
}

to this:

{
  "id": "{{{user_id}}}",
  "access_token": "Jo1UqrNg4kVWjUOem9ebyp2wMrS3h3aEi0GvPRiIKCe03RCbCpDZTDAvsIAmOFlb",
  "filter": "{\"where\":{\"workoutId\":14}}"
}

I can get the output response that I want. So I am really confused about how setup needs to be in order to get the desired response.
image


#4

You reference a {value_id} (which should actually be wrapped in double or tripple curly braces) but your data string does not contain such a key - how would the webhook/integration know what value to use?

I’m also somewhat confused about your actual data flow and also some of your terminology (e.g. response template vs. custom request body)

Could you explain

  • what data (without any “decoration” or formatting) you want your device to send to the webhook
  • what the webhook should then send to your target server (formatted as the server expects to see it)
  • what you expect to get back from the server to the webhook (formatted as is)
  • what you want to get from the webhook delivered back to your device (this is what the response template defines)

(the first two bullets refer to the request while the latter two refer to the response)

Could you also post the webhook definition (via the CUSTOM TEMPLATE tab in the integrations edit page).

I think you are overcomplicating the matter. Webhooks/integrations are meant to add some level of abstraction between the device and the target server and hence reduce complexity of the request message the device has to create.
Your device should only need to care about the most important data while the webhook/integration takes care of properly formatting the request.


possible solution

If you only want to send userID and workoutID to the webhook and want the webhook to wrap the workoutID into your request variable you could create a simple JSON on the device like this

  char reqData[64];
  snprintf(reqData, sizeof[reqData], "{ \"userID\": \"%d\", \"woID\": \"%d\" }", my_id, my_workoutId);
  // expected format: { "userID": "123", "woID": "456" }
  Serial.println(reqData); // always check how the string looks on the device ;-)
  Particle.publish("workout_rest", reqData, PRIVATE);

and reference these values in the webhook like this

{
  "id": "{{userID}}",
  "access_token": "xxx",
  "filter": "{ \"where\": { \"workoutId\": {{woID}} } }"
}

That is the beauty of webhooks, your request string from the device to the cloud doesn’t need to know anything about the actual format of your request towards the server. Your device only sends the dynamic data which then gets inserted into the request template according to the format the server requires.

For maintenace and readability it’s also good to use different names/keys so that you can distinguish which is the incoming and what the outgoing data (e.g. incoming "userID" goes out as "id" and incoming "woID" goes out as "workoutId").


#5

Hey @ScruffR

I was definitely confused about how data flow should be sent to the cloud.

Your proposed solution works!!! :smile:

Yes, I was basically overcomplicating the matter, I thought that I had to send to the particle cloud the same formatted data as it was in the query parameters defined.

Thank so much for your time and also for the tips! :grin: