Magento2: REST API : Save Product Detail per store view not working

[emizentech]

Steps to reproduce

1. Install Magento from 2.1 branch.
2. Deploy Sample Data
3. Using REST API catalogProductRepositoryV1 REF: http://devdocs.magento.com/swagger/index.html

Get Key from Admin token API
and use that key in

POST /V1/products
PUT /V1/products/{sku}
with parameter tried with both parameter one by one

• store_id=0
• storeId=0
  using following JSON

{
    "saveOptions": "true",
    "product": {
        "name": "Test11_11",
        "sku": "TESTOPP_111",
        "attributeSetId": "15",
        "price": "10",
        "weight": "10",
        "status": "1",
        "visibility": "3",
        "customAttributes": [
            {
                "attributeCode": "manufacturer",
                "value": "222"
            },
             {
                "attributeCode": "store_id",
                "value": "0"
            },

            {
                "attributeCode": "tax_class_id",
                "value": "0"
            },
            {
                "attributeCode": "specialPrice",
                "value": "10"
            },
            {
                "attributeCode": "description",
                "value": "44332211"
            },
            {
                "attributeCode": "eco_collection",
                "value": "1"
            }
        ],
        "typeId": "simple"
    }
}

Does not support store_id / storeId field ,
but the information in product does not save to store
it save to default Store ID

GET /V1/products has parameter storeId
same i had tried with PUT & POST but not working with PUT & POST

[emizentech]

i have solved this by overriding StoreManager
more details can be found here :
http://stackoverflow.com/questions/37744874/magento2-rest-api-save-product-detail-per-store-view-not-working

[AirmanAJK]

Same problem here using the SOAP API in 2.1.0. Updating custom attributes ends up inserting new product attribute values in the database with store_id = 1. This DID NOT happen in 2.0.7 where it would update my existing value for store_id = 0.

Updating using the admin area did not cause this issue.

[andimov]

@emizentech
Thank you for reporting and providing a solution!
@AirmanAJK
Did you try to use this solution? http://stackoverflow.com/questions/37744874/magento2-rest-api-save-product-detail-per-store-view-not-working

[andimov]

According to contributor guide, tickets without response for two weeks should be closed.
Please feel free to reopen if it's needed.

[george-vlahakis]

Fixed in 2.1.3

[geon]

It is not fixed in 2.1.3.

It appears to have been fixed in 4d1c7e8e4d06a93333503598174ee534e9837614 , but I can't try it atm.

[kanduvisla]

I also can confirm that this is not fixed in 2.1.3.

When I POST a product, all attribute values are saved with store_id = 0; After a second, identical request, some (not all) values are saved on store_id 1. Note that the values that are saved for store_id 1 aren't event present in my original request!

This is the request:

{
    "product": {
        "sku": "ROCA-ROC-13-L",
        "name": "La Roca Insert White",
        "attribute_set_id": 4,
        "price": 25,
        "visibility": 1,
        "type_id": "simple",
        "custom_attributes": [{
            "attribute_code": "meta_title",
            "value": "La Roca Insert White"
        }, {
            "attribute_code": "meta_keyword",
            "value": "La Roca Insert White"
        }, {
            "attribute_code": "meta_description",
            "value": "La Roca Insert White"
        }]
    }
}

After the second time this request is sent, the following attributes are re-saved for store_id = 1:

• enabled / status
• name
• tax class
• visibility
• everything under SEO : url_key, meta keywords, title and description
• display product options in ...

Please, can anyone confirm this bug and reopen this ticket? This behaviour pretty much makes using the REST API pretty frustrating, since you'll end up with clutter in your database everytime the API is called. Especially when you think you changed a products' attribute, but then later on discover there was a value on storeview-level that is overriding your changes!

edit:
A workaround currently to make sure it only is updated for store_id = 0 is by using this suggestion and adding all to the URL:

POST http://www.domain.com/rest/all/V1/products

This will give the expected behaviour. However, I still the current behaviour should be considered a bug since doing the same request twice results in different results.

[misha-kotov]

I don't believe what you're describing is a bug. First, there should be no expectation that sending two identical POST requests should result in identical results, as the POST method is not idempotent. POST requests should be used only to create entities, not update them. You should be using PUT to update entities.

What seems to happen in this case is that the first POST results in a "create" and the second one is interpreted as an update to the previously created product.

A bit about scopes: all products have some attributes that you can override on a store view level. What you see on a product in an "all store views" scope can be thought of as a "template" of default values that can be overridden in a store view scope. When updating products via REST, the default store view scope is assumed, unless explicitly specified like you mentioned, or in devdocs here. When the product first gets created, the values provided for website-scoped fields are assumed to be on the "template" level ("All Store Views" scope) and not overridden on the store view level. Also during creation, the product's website assignment is based on the default store view, unless explicitly specified.

Admittedly, the documentation on scopes in APIs is lacking a bit, and we'll work on improving it (cc: @keharper, @tanberry ). The takeaway is that it should be a best practice to explicitly specify scopes for API operations whenever possible - that way you don't rely on system assumptions.

Finally, I'd like to dig into the issue of certain fields (ex: tax class) being set when the values are not specified in the payload. Can you confirm this happens when you update the product using the PUT method? Do they show up as overridden in the Store View level in the Admin UI?

[ivan-krechko]

Hi,

unfortunately, it doesn't work for us too. We have Magento 2.1.7 and only
rest/all/V1/products
works with PUT. But it is setting all the websites for the product, even if the website_id is sent.

It is the serious issue, I think...

Regards, Ivan

[keevitaja]

To update product for a store view, you can use rest/store_view_code_not_id/V1/products/sku and then PUT json:

{
    "product": {
        "name": "In english",
        "custom_attributes": [
            {
                "attribute_code": "description",
                "value": "simple description"
            },
            {
                "attribute_code": "short_description",
                "value": "short desc desktription"
            }
        ]
    }
}

[ivan-krechko]

Hi keevitaja,

thanks for the response. We have tried this. Unfortunately, it is not working for us...

Regards, Ivan

[keevitaja]

Strange... it is working on 2.1.5 community edition. I can try later some other version too

http://????.com/rest/somecode/V1/products/toode

[ivan-krechko]

OK, it would be great if you'll try on 2.1.7.
Thank you, keevitaja.

Regards, Ivan

[adbelkina]

@AirmanAJK for soap I found this solution. Basically you should substitute parameter name 'storeView' with 'store'
https://www.nportais.org/blog/en/2015/01/25/magento-api-sore-and-not-storeview/#comment-73

[ivan-krechko]

Hi @adbelkina,

thanks for your comment. But I have no clue, how you used it.

[2017-07-19 08:30:19] main.CRITICAL: LogicException: Property "Store" does not have corresponding setter in class "Magento\Catalog\Api\Data\ProductInterface". in /var/www/html/lib/internal/Magento/Framework/Reflection/NameFinder.php:100
Stack trace:
#0 /var/www/html/lib/internal/Magento/Framework/Reflection/NameFinder.php(59): Magento\Framework\Reflection\NameFinder->findAccessorMethodName(Object(Zend\Code\Reflection\ClassReflection), 'Store', 'getStore', 'isStore')
#1 /var/www/html/lib/internal/Magento/Framework/Webapi/ServiceInputProcessor.php(158): Magento\Framework\Reflection\NameFinder->getGetterMethodName(Object(Zend\Code\Reflection\ClassReflection), 'Store')
#2 /var/www/html/lib/internal/Magento/Framework/Webapi/ServiceInputProcessor.php(322): Magento\Framework\Webapi\ServiceInputProcessor->_createFromArray('Magento\\Catalog...', Array)
#3 /var/www/html/lib/internal/Magento/Framework/Webapi/ServiceInputProcessor.php(119): Magento\Framework\Webapi\ServiceInputProcessor->convertValue(Array, 'Magento\\Catalog...')
#4 /var/www/html/app/code/Magento/Webapi/Controller/Rest/InputParamsResolver.php(101): Magento\Framework\Webapi\ServiceInputProcessor->process('Magento\\Catalog...', 'save', Array)
#5 /var/www/html/app/code/Magento/Webapi/Controller/Rest.php(299): Magento\Webapi\Controller\Rest\InputParamsResolver->resolve()
#6 /var/www/html/app/code/Magento/Webapi/Controller/Rest.php(216): Magento\Webapi\Controller\Rest->processApiRequest()
#7 /var/www/html/var/generation/Magento/Webapi/Controller/Rest/Interceptor.php(24): Magento\Webapi\Controller\Rest->dispatch(Object(Magento\Framework\App\Request\Http))
#8 /var/www/html/lib/internal/Magento/Framework/App/Http.php(135): Magento\Webapi\Controller\Rest\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#9 /var/www/html/lib/internal/Magento/Framework/App/Bootstrap.php(258): Magento\Framework\App\Http->launch()
#10 /var/www/html/pub/index.php(37): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http))
#11 {main}

Next Exception: Report ID: webapi-596f189bda176; Message: Property "Store" does not have corresponding setter in class "Magento\Catalog\Api\Data\ProductInterface". in /var/www/html/lib/internal/Magento/Framework/Webapi/ErrorProcessor.php:195
Stack trace:
#0 /var/www/html/lib/internal/Magento/Framework/Webapi/ErrorProcessor.php(139): Magento\Framework\Webapi\ErrorProcessor->_critical(Object(LogicException))
#1 /var/www/html/app/code/Magento/Webapi/Controller/Rest.php(219): Magento\Framework\Webapi\ErrorProcessor->maskException(Object(LogicException))
#2 /var/www/html/var/generation/Magento/Webapi/Controller/Rest/Interceptor.php(24): Magento\Webapi\Controller\Rest->dispatch(Object(Magento\Framework\App\Request\Http))
#3 /var/www/html/lib/internal/Magento/Framework/App/Http.php(135): Magento\Webapi\Controller\Rest\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#4 /var/www/html/lib/internal/Magento/Framework/App/Bootstrap.php(258): Magento\Framework\App\Http->launch()
#5 /var/www/html/pub/index.php(37): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http))
#6 {main} [] []

Regards,
Ivan

[Lukas1Komarek]

@adbelkina Your linked article is describing a problem in Magento 1.X

[marvinhinz]

I don't believe what you're describing is a bug. First, there should be no expectation that sending two identical POST requests should result in identical results, as the POST method is not idempotent. POST requests should be used only to create entities, not update them. You should be using PUT to update entities.

What seems to happen in this case is that the first POST results in a "create" and the second one is interpreted as an update to the previously created product.

A bit about scopes: all products have some attributes that you can override on a store view level. What you see on a product in an "all store views" scope can be thought of as a "template" of default values that can be overridden in a store view scope. When updating products via REST, the default store view scope is assumed, unless explicitly specified like you mentioned, or in devdocs here. When the product first gets created, the values provided for website-scoped fields are assumed to be on the "template" level ("All Store Views" scope) and not overridden on the store view level. Also during creation, the product's website assignment is based on the default store view, unless explicitly specified.

Admittedly, the documentation on scopes in APIs is lacking a bit, and we'll work on improving it (cc: @keharper, @tanberry ). The takeaway is that it should be a best practice to explicitly specify scopes for API operations whenever possible - that way you don't rely on system assumptions.

Finally, I'd like to dig into the issue of certain fields (ex: tax class) being set when the values are not specified in the payload. Can you confirm this happens when you update the product using the PUT method? Do they show up as overridden in the Store View level in the Admin UI?

I think you are right that this behaviour is ok with POST, although a bit confusing. But i still have reproduced this with two identical PUT requests. The first time, a single product in the admin store is created, the second time a copy is created in the default "de" store, with only some fields being moved over. This is pretty unexpected behaviour, as its not idempotent. Is there a reason why attributes are moved to a scope only on update and not on creation?