akuity
Support JSON Array Responses in HTTP Step
Title: Support JSON Array Responses in HTTP Step
Checklist
- [x] I've searched the issue queue to verify this is not a duplicate feature request.
- [x] I've pasted the output of
kargo version, if applicable. - [x] I've pasted logs, if applicable.
Proposed Feature
Add support for handling JSON array responses in the HTTP step. Currently, the HTTP step expects all JSON responses to be objects (map[string]any), but many REST APIs return arrays of objects.
Example error when receiving an array response:
step execution failed: step 0 met error threshold of 1: failed to run step "http": error building expression context from HTTP response: json: cannot unmarshal array into Go value of type map[string]interface {
Motivation
Many REST APIs return arrays by default, especially when fetching lists of resources. Some examples:
- GitLab API's merge request endpoints (
/api/v4/projects/{id}/merge_requests) - GitHub API's PR endpoints
- Most REST APIs that return collections
This limitation prevents users from using common REST API endpoints directly in their promotion workflows.
Suggested Implementation
- Modify the
buildExprEnvfunction inhttp_requester.goto handle both object and array responses:
if len(bodyBytes) > 0 && contentType == contentTypeJSON {
// Try unmarshaling as array first
var bodyArray []any
if err = json.Unmarshal(bodyBytes, &bodyArray); err == nil {
env["response"].(map[string]any)["body"] = bodyArray
} else {
// Fall back to object unmarshal
body := map[string]any{}
if err = json.Unmarshal(bodyBytes, &body); err != nil {
return nil, err
}
env["response"].(map[string]any)["body"] = body
}
}
- Update the expression syntax to support array access:
outputs:
- name: firstMrTitle
fromExpression: "response.body[0].title" # Access first item in array
- name: allTitles
fromExpression: "response.body[*].title" # Get all titles
This would maintain backward compatibility while adding support for array responses.
Thanks for raising this. Agree. This should be pretty easily done, although I don't believe any updates to how expressions are evaluated is required. In fact, we don't even define the syntax. It's all expr-lang.
Maintainers' priorities are largely driven by customers. +1'ing adds needless clutter tho these threads and doesn't change our prioritization.
The proposal label was already removed from this issue, meaning this is a change that's passed our initial scrutiny and we have no objections to it. The issue is additionally labeled a "help-wanted" and "good first issue," which are both pretty good indicators that we are leaving it up to the community to handle this issue.
The beauty of open source is that anyone can contribute. Please consider having a go at this very simple issue instead of +1'ing.
