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]

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)

• 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]

Beep boop 🤖

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

• There's nothing new to document 🤔
• I'll do it later 😞

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

• I just updated 🎉🎉

[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).

[garrucho]

I'm worried about completely changing from POST to GET. I think there are proper moments for each of them.

I'd say that GET fits only to single-item simulations that are made by the Intelligent Search. It may be risky or even not beneficial enough to change it for every simulation made by this GraphQL.

[garrucho]

I'd also consider creating a test for a nested null parameter to be safe about requests without regionId, which are frequent.

So, this:

{
  ...
  shippingData: {
      logisticsInfo: [{ regionId: null }],
  }
}

Should generate the parameter &request.shippingData.logisticsInfo[0].regionId= or completely omit the property (including the shippingData part of it).

The first option is recommended if you want to keep the same semantics as the POST requests we do nowadays – if there's no specific value, it always sends the "regionId" as null.

I'm highlighting this because the nullParameter: null was completely omitted, which is not a problem, but won't be the same and I don't know how it would be while nested.