How to check the "Do HTTP(S) request Action" response status
New
Hello,
We have use the "Do HTTP(s) request Action in the Event Rules to make a call to our WebAPI. It works but when our API not return a 200 OK or nothing, the NX Withness software will act of this call is perfect send and handled.
Can we trigger an action or something when the Http Call isn't right handled ?
Gr.
Michiel
-
Hi M Boulonois,
Thanks for your questions.
Unfortunately, I did not see the return code or the response now either.
I believe this is a good suggestions. Let me talk to the internal product management team if this is on the roadmap or anything we can do about it. -
Hello Ichiro, Thanks for your answere.
Maybe you can also discus the /api/createEvent call.
It works, but when we add an Description in the body that not exist in the system we get no error from the call. So can't make sure that the Event Rule is succesfull find in the system and is triggerd.
Also in the response we see:
"{\"error\":\"0\",\"errorId\":\"ok\",\"errorString\":\"\"}"
But the eventRule isn't exist in the system.
Gr.
Michiel
-
Hi M. Boulonois,
I wanted to share my thoughts on the two different levels of handling HTTP requests:
1) HTTP Request Action
I agree that it's essential to check the return code of an HTTP request to determine if it was "successful."
A return code indicates that the endpoint received the request, but this doesn't necessarily mean it was processed correctly. For example, the return codes could be 200, 307, 401, 404, 503, etc. I believe this approach is valuable and can greatly benefit partners looking to utilize this action.2) Event Rule Creation and Matching
It's important to note that if the rules were not created on the Nx Desktop client, or if the request did not match the rules, this should not be considered a failure.Once the mediaserver receives the request, it is considered successful. (HTTP 200 OK , no error)The "Do HTTP Request" action can be sent to any endpoint in several formats or methods. We aim to keep the usage flexible and not limit it to the Nx mediaserver only.
In other word, if a request does not match the rules due to human judgment, this should not be explicitly treated as a "Failed" or "Error" state. The reason is that it is not a failure but rather a case of the request not matching the defined rules for specific reasons. The mediaserver still executes the procedure of comparing; it just does not trigger due to the rules not being matched.
Since the content of requests and rules can only be defined by users and not generalized in a system, we currently do not think this should be included in the procedure. We appreciate your idea and feedback and will keep this in the backlog for future discussion. Thank you for your understanding.
Please sign in to leave a comment.
Comments
4 comments