#29334 Status code as argument for responses in REST requests

enhancement

minor

#29334

Status code as argument for responses in REST requests

defect

major

#29223

Commands configured directly in the dialog cannot be granted permissions.

#29269

Kafka: Error when handling null messages

#29272

Import in help editor does not work

#29325

Generated JSON schema marks a non-nullable layout-template property (dialog title) as nullable/optional

#29338

CreateTLSingletonProcessor creates duplicate annotations

#29373

Buttons Do Not Respond to Programmatic DOM Clicks (UI Test Automation with Playwright)

minor

#28685

Authorization Issues in Model-Based Search

#29009

Selection in tree invisible if "Expand on selection" is not selected

#29322

Configuration Command Undo vs List of changes

#29330

TreeTableComponent / TreeComponent loses state on invalidate

#29331

Zoom level to be retained

#29339

Failed migration in #28305

#29340

TL Script: Optimizing database queries with transient objects fails

#29367

Error in the TL Script Compiler when parsing HTML literals as the first expression in a block

#29371

Values of macro attributes are not displayed

#29372

Flowchart: Problems with a compact tree layout and overlapping elements in combination with a zigzag display

#29379

Script Recorder: Details Can No Longer Be Edited After Moving a Selected Action

enhancement

minor

#29334

Status code as argument for responses in REST requests

IntegrationAPI

If you configure a third-party REST API (Service Editor > TL script functions for external APIs), you can include a response header value as additional arguments in the response processing, but not the actual status code that the response provides.

You can handle individual status codes separately, but in "general" response processing you cannot determine which status code the response has:

Usually you have a positive response (e.g. status code 200) and a set of error codes (400, 401, ...) that you want to handle differently from the positive response. Currently, you have to configure an extra treatment for each individual status code, otherwise you will not have the status code.

It would therefore be good if the status code could be passed as an extra argument for (at least general) post-processing.

Implementation

In the "Additional arguments" section, "Response status code" can be selected and this can then be used in processing.