use get instead of post when requesting the simulation API

[hiagolcm]

What problem is this solving?

Jira card

The simulation API only caches the result when it's called via a GET request. Currently we call it via a POST request.

In order to the benefits from the cache, this PR changes the method from POST to GET.

How to test it?

Workspace

[vtex-io-ci-cd[bot]]

Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖

Please select which version do you want to release:

• [ ] Patch (backwards-compatible bug fixes)

• [x] Minor (backwards-compatible functionality)

• [ ] Major (incompatible API changes)

And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.

• [ ] No thanks, I would rather do it manually 😞

[vtex-io-docs-bot[bot]]

Beep boop :robot:

I noticed you didn't make any changes at the docs/ folder

• [x] There's nothing new to document :thinking:
• [ ] I'll do it later :disappointed:

In order to keep track, I'll create an issue if you decide now is not a good time

• [ ] I just updated :tada::tada:

[hiagolcm]

@garrucho Do you think the URL maximum length could be exceeded when the simulation payload has too many items? I think if it was the case we would already have problems since the catalog already uses the GET method, but I would like to have your perception about it

We could add a POST request as fallback for example. what do you think?

[garrucho]

@garrucho Do you think the URL maximum length could be exceeded when the simulation payload has too many items? I think if it was the case we would already have problems since the catalog already uses the GET method, but I would like to have your perception about it

We could add a POST request as fallback for example. what do you think?

Yes, this is a possible problem! But the simulations made by Portal/Catalog, so the Search, should always contain only a single item, reducing the chance for problems.

Simulation requests with multiple items are characterized as a cart and can generate problems while retrieving conditions for a shelf/storefront, which shows individual items.

A function to limit GET only to when the items array has a single object is welcomed. And/or, you can also consider checking the length of the generated URL to fallback it as POST if higher than a number (to be defined; the limit also includes the URL host).