Skip to content

INT-221: predictivebasket example for kastner#538

Draft
Rayn93 wants to merge 1 commit intorelease/5.xfrom
INT-221
Draft

INT-221: predictivebasket example for kastner#538
Rayn93 wants to merge 1 commit intorelease/5.xfrom
INT-221

Conversation

@Rayn93
Copy link
Contributor

@Rayn93 Rayn93 commented Feb 12, 2026

predictivebasket example for kastner

@fritzmg
Copy link
Contributor

fritzmg commented Feb 12, 2026

My main point was that ideally I should be able to use the rest/v5/predictivebasket/… endpoint just like any other endpoint with the provided PHP SDK. Within our application it would be inconvenient to implement special handling just for the rest/v5/predictivebasket/… endpoint (though it is of course possible to do).

@Rayn93
Copy link
Contributor Author

Rayn93 commented Feb 13, 2026

Hi @fritzmg

thanks for the constructive discussion — we fully agree that the correct place for this fix is the SDK layer.

We will add this improvement to our development backlog and implement proper query normalization inside the SDK, so that array parameters like blacklist are automatically sent as repeated query parameters without indices.

However, this change will most likely be a breaking change, because it modifies how query parameters are serialized at a very fundamental level. For that reason, it will be released together with the next major SDK version, rather than as a patch or minor update.

Until the new SDK version is released, we recommend applying the workaround on the application side, i.e. manually flattening array query parameters when calling the rest/v5/predictivebasket/... endpoint, as discussed earlier.

@fritzmg
Copy link
Contributor

fritzmg commented Feb 13, 2026

But wouldn't it be much easier to transform the query parameters on the server's side? e.g. at the level of the web server, via an NGINX NJS module or something.

@Rayn93
Copy link
Contributor Author

Rayn93 commented Feb 13, 2026

That’s a good suggestion — I will check this internally with the team responsible for the API and ask whether a server-side normalization would be acceptable.

But to be honest, based on our previous experience, it is quite unlikely that they would want to introduce such request rewriting on the API / infrastructure layer, mainly due to avoiding hidden request transformations and keeping a strict and predictable API contract.

Because of that, the most realistic and sustainable solution remains fixing this on the SDK side, where we can properly normalize query parameters in a controlled, transparent, and testable way.

@Rayn93
Copy link
Contributor Author

Rayn93 commented Feb 24, 2026

Hi @fritzmg

The server-side normalization would not be acceptable by API team that's why I implemented query array normalizer middleware on library layer: FACT-Finder-Web-Components/php-communication-sdk@75cd321

@fritzmg
Copy link
Contributor

fritzmg commented Feb 24, 2026

Sounds good 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants