Magento 2 API Structure - Store Code in the wrong place?

[rain2o]

The Issue

There seems to be some discrepancy with how Magento 2 documents their API endpoint structure and how they actually call the API in standard Magento front-end (using standard Luma theme). VSF builds the API based on the documented structure, which theoretically is correct, but I have found it causes some issues.

For the purposes of the following information and examples, let's use https://shop.example.com as the Magento 2 domain. Also, /index.php is optional for Magento sites based on your configuration, so I'll try to keep it out for simplicity.

Magento's documentation suggests the endpoint is structured as {protocol}://{domain}/{web_service}/{store_code}/V1/{endpoint}. Store code can be a valid store code, or it can be default for the default store, or all for some endpoints which can impact all stores. For example https://shop.example.com/rest/default/V1/customerGroups/:id for calling customer groups for the default store using the REST web service.

Vue Storefront uses this structure for building the Magento 2 API endpoints, and it works with multistore as it should. However, I ran into an issue where this isn't working properly, and after testing with Magento's Luma frontend, I notice that they use a different API structure. Instead, they use the following - https://shop.example.com/{store_code}/rest/{store_code}/V1/{endpoint}. Basically they inject an extra store_code before the web service rest.

A Real Example

This discovery is a result of a real issue I'm having. I'll provide the details below to help clear up any potential confusion hopefully.

Using the official Stripe M2 module, I have enabled Stripe Credit Card payment method for all store views. And then for a store view with store code nl_nl only I have enabled the iDeal payment method. After doing this I tested 4 different ways - Magento front-end (Luma theme), Vue Storefront, Swagger, and Postman.

Testing and Results

Magento Front-end: Browsing the store where iDeal is enabled, I went through the checkout process and iDeal showed as an available payment method. Looking at the network calls, the following call was made - https://shop.example.com/nl_nl/rest/nl_nl/V1/guest-carts/UrHE2W1L7HtNg2RMdgdhiTTvdm23czmS/shipping-information. The result was both Stripe CC and iDeal, which is correct based on my configuration.

Vue Storefront: Again, browsing the nl_nl store view, I went through the checkout flow, but only the CC payment method was available. Watching the logs of VSF-API and Magento, I noticed the following call was made - https://shop.example.com/rest/nl_nl/V1/guest-carts/UrHE2W1L7HtNg2RMdgdhiTTvdm23czmS/shipping-information. The result was only Stripe CC payment method being returned. This is incorrect, iDeal was missing.

Swagger: Testing directly in swagger the /V1/guest-carts/:cartId/shipping-information endpoint, the full URL which was called is https://shop.example.com/index.php/en_us/rest/nl_nl/V1/guest-carts/UrHE2W1L7HtNg2RMdgdhiTTvdm23czmS/shipping-information. Notice theen_usbeforerest? That's my default store code... not sure why Swagger is using that, but nonetheless it has a storecode beforerest, and another one after. The result was only the one payment method, but this is becauseen_us` was used at the beginning. Strange, but still tracks with my findings.

Postman: Finally, I did some testing in Postman to see what I could get working. Calling https://shop.example.com/nl_nl/rest/V1/guest-carts/UrHE2W1L7HtNg2RMdgdhiTTvdm23czmS/shipping-information (the same as Magento Front-end) gave me the expected results - both payment methods. Then calling https://shop.example.com/rest/nl_nl/V1/guest-carts/UrHE2W1L7HtNg2RMdgdhiTTvdm23czmS/shipping-information (the structure from the documentation, and the same as VSF), the result is the incorrect payment methods (missing iDeal).

I'm not so sure if this is a bug in Magento or Vue Storefront, or perhaps a case of incorrect documentation from Magento (in which case would be a bug in VSF, but only because of misguided documentation). I wanted to post here to see if we can come up with a solution, or find out exactly what the problem is and where it needs to be fixed.

[rain2o]

I also opened an issue with Magento at https://github.com/magento/magento2/issues/24071. I tested in the sandbox and wasn't able to replicate my specific example, so I'm going to continue testing locally. However, I'm still waiting for a response about the difference between what is documented and what is actually used in the structure of the endpoints.

[pkarw]

Hi Joel thanks for pointing this one out. I'm just wondering - if it's a case of different URL format isn't the solution just to change the URLs in the config/local.json -> magento2.api.url kind of thng?

[rain2o]

Hi @pkarw, the problem comes in when VSF builds the URL for multi store. If I remember correctly it constructs the endpoint using the endpoint and store code from config, but I don’t think we can control where it places the store code. I’ll have to check again though.

[pkarw]

OK, if so I think that the general solution would be to take the config from config file instead of doing this kind of concatenation ...

I can't check it right now (waiting for a plane boarding in 5m) - but look at this one: https://github.com/DivanteLtd/vue-storefront-api/blob/589bb876fd32077124f82d7e0ded67d440ff7129/src/platform/magento2/util.js#L7

[rain2o]

After further testing and upgrading to the most recent version of Magento 2.3.2, it seems to have been something with using 2.3.1. The issue is no longer happening from what I can tell. I have opened a related bug asking for clarification around the API structure discrepancy in the dev docs. This issue can be closed for now, and if an update to the devdocs indicates the structure of the API should be different than it currently is then I will revisit this.