INT-221: predictivebasket example for kastner#538
Conversation
|
My main point was that ideally I should be able to use the |
|
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. |
|
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. |
|
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. |
|
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 |
|
Sounds good 👍 |
predictivebasket example for kastner