oEscal opened a new issue, #3936: URL: https://github.com/apache/incubator-kie-kogito-runtimes/issues/3936
### Description Currently, the behavior of REST custom functions is that if the requested endpoint returns an HTTP response with a code between 200 and 300, the function will return the response body as JSON. However, this is a bit constraining for developers. First, if the endpoint returns an error status code, the workflow throws an error and fails. But I, as a developer, might want to have some logic around getting error responses. For instance, if an endpoint responds with a 400 status code, I might want to run a function that handles the error. Response headers are entirely ignored. However, similar to the status code, I might want to have logic around response headers' values. I might also want to send them as headers or even in the request body to the following function. Ultimately, I think it should be up to developers to decide what to do with headers and status codes if they choose to do so. ### Implementation ideas First, I think it is a good idea to maintain the current behavior as the default for backward compatibility. Therefore, we can divide this feature into three options: `the function failing when it gets an error status code` (default to `true`); `return headers` (default to `false`), and `return status code` (default to `false`). Similar to the host or port, these values could then be controlled by related properties. For instance: - function failing when it gets an error status code: `kogito.sw.functions.<function name>.fail_on_status_error` - return headers: `kogito.sw.functions.<function name>.return_headers` - return status code `kogito.sw.functions.<function name>.return_status_code` Then, depending on whether the properties are set or not, the function returns the headers and status code and does not fail when getting a status code below 200 or bigger than 300. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
