Details
-
Improvement
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
-
-
Empty show more show less
-
Yes
-
Declarative REST 13, Declarative REST 14, Declarative REST 15
-
8
Description
Currently, if a REST call fails a developer has no information about the REST call, and does not even necessarily know if it failed.
It's tricky for a developer because the problem could be in many places: in the restclient definition, or it could be with the external service itself, or it could be in the FTL or in the App configuration. Its easy to introduce a problem in the call since the calls themselves are often dynamically constructed.
Acceptance Criteria:
- An error while making a REST call should be written to the log.
- Dedicated log file?
- All details about the request and response should be included - body, cookies, headers, parameters.
- Secure information should not be written to the log.
Additional ideas for later:
- Secure info is only written when the server is in developer mode.
- If call can be written in a format compatible with 'curl' that is a bonus, because then developers could try it.
Checklists
Attachments
Issue Links
- depends upon
-
MGNLRESTCL-43 Handle errors in a REST response
-
- Closed
-
- is causing
-
MGNLRESTCL-133 DOC: Debug subapp in the REST Client app
-
- Closed
-
- supersedes
-
MGNLRESTCL-101 Log of most recent REST client calls and their response
-
- Closed
-
- mentioned in
-
Page Loading...