Product category endpoints

[Codencode]

Questions	Answers
Description?
Type?	improvement
BC breaks?	no
Deprecations?	no
Fixed ticket?
Sponsor company	Codencode snc
How to test?

How To Test - Product Category Endpoints

Create an API Client with these scopes:
product_write

---

Query 1 - Assign Product to Category

Method: POST
URI: /products/{productId}/assign-to-category
Example: /products/1/assign-to-category

Body

{
  "categoryId": 3
}

Response

• HTTP 201 Created

{
  "productId": 1,
  "categories": [
    {
      "id": 3,
      "name": "Clothes",
      "displayName": "Clothes"
    }
  ]
}

---

Query 2 - Set Associated Product Categories

Method: POST
URI: /products/{productId}/categories
Example: /products/1/categories

Body

{
  "categoryIds": [3, 4, 5],
  "defaultCategoryId": 5
}

Response

• HTTP 201 Created

{
  "productId": 1,
  "defaultCategoryId": 5,
  "categories": [
    {
      "id": 3,
      "name": "Clothes",
      "displayName": "Clothes"
    },
    {
      "id": 4,
      "name": "Men",
      "displayName": "Men"
    },
    {
      "id": 5,
      "name": "Women",
      "displayName": "Women"
    }
  ]
}

---

Query 3 - Remove All Associated Product Categories

Method: DELETE
URI: /products/{productId}/categories
Example: /product/1/categories

Body

Nessun body richiesto.

Response

• HTTP 204 No Content

---

[ga-devfront]

While the PR is in draft, I am taking the liberty of removing the review request.

[Codencode]

While the PR is in draft, I am taking the liberty of removing the review request.

Oh yes, you're right, I hadn't thought of that 🙏

[Codencode]

To display the list of categories in the response, I created PrestaShop\Module\APIResources\Serializer\ProductCategoryOutputNormalizer, which enables generating a tailored response for ProductForEditing, but only for the ProductCategory API.

I implemented this control by checking the use_product_category_normalizer key defined in ProductCategory::QUERY_MAPPING.
If there's a better way to do this, please let me know.

Thank you!

[jolelievre]

The options for normalization shouldn't be in this field which is a pure PrestaShop custom field It should be in the normalization context instead

But I think we should be able to handle this use case without relying on a normalizer, but first I have one question: should this endpoint return the full product? or only the part with the categories?

Ideally, we should keep it simple and only return the list of associated categories, the thing is we don't have such a query and the API is only meant to be a bridge to the existing CQRS classes, because of this limiation the list of associated categoruies can only be fetch via GetProductForEditing

Which means the categories should be displayed in the return of this endpoint, but to do that this whole API resource should have the same fields as the PrestaShop\Module\APIResources\ApiPlatform\Resources\Product\Product resource, so it should probably extend it which can be a bit overkill

OR we can decide that this update endpoint doesn't return data and simply indicates if it succeeded by returning a no response 204, and to check the modified content we can use /products/1, if so then the missing mapping needs to be added on PrestaShop\Module\APIResources\ApiPlatform\Resources\Product\Product

[jolelievre]

I tried to use mapping to handle the categories properly in this PR #116

But it required another modification in the core so that I can rename the categoryId properly We could have kept the id in the sub object, but it doesn't really respect the expected convention (IDs should be prefixed with their associated resource), so I preferred to do this POC to see if we can handle it as expected

[Codencode]

@jolelievre

But I think we should be able to handle this use case without relying on a normalizer, but first I have one question: should this endpoint return the full product? or only the part with the categories?

I believe the response should only include the part with the categories.

Which means the categories should be displayed in the return of this endpoint, but to do that this whole API resource should have the same fields as the PrestaShop\Module\APIResources\ApiPlatform\Resources\Product\Product resource, so it should probably extend it which can be a bit overkill

Yes, I think it's excessive too ;-)

OR we can decide that this update endpoint doesn't return data and simply indicates if it succeeded by returning a no response 204, and to check the modified content we can use /products/1, if so then the missing mapping needs to be added on PrestaShop\Module\APIResources\ApiPlatform\Resources\Product\Product

It's the first solution I implemented, then I added a commit with the creation of the normalizer (this was following our conversation on Slack).

I tried to use mapping to handle the categories properly in this PR #116
But it required another modification in the core so that I can rename the categoryId properly We could have kept the id in the sub object, but it doesn't really respect the expected convention (IDs should be prefixed with their associated resource), so I preferred to do this POC to see if we can handle it as expected

I couldn't understand this point, maybe I didn't translate it well or I'm having trouble following your reasoning 😅

[jolelievre]

You should add these endpoints earlier in the workflow, you can pass it the $productId this way you can test these changes on the newly created product instead of hard-coded ID 1

[Codencode]

If I understand correctly, I should make the test testAssignProductToCategory() dependent on the test testPartialUpdateProduct() in order to receive the product id as input, right?
But the category id would still be hardcoded in the method?

[nicosomb]

@Codencode one test is red

[Codencode]

@Codencode one test is red

@nicosomb, yes I know, I asked @jolelievre because there's an issue between the documentation and the Rector Dry Run. He will decide how to proceed.

Thanks for the heads-up 😃

[jolelievre]

Hi @Codencode

for this one you can update ApiResourceUriTemplateRector::SKIPPED_KEYWORDS and add assign-to-category in it This array contains the exceptions for words we accept as singular forms, mostly actions. But there are a few relevant singular words like cover

[Codencode]

Hi @jolelievre,

I've made the change, I hope I understood correctly 😄.

Thanks!

[kpodemski]

Hello @Codencode

There's a conflict in services.yml that probably appeared when we merged another PR. Could you resolve it?

[Codencode]

Hello @kpodemski
Solved.

Thank you!

[kpodemski]

Hello @Codencode

Just a quick heads-up: reviews on pending Admin API PRs will start in the coming days.

We first took some time to clarify and unify the Admin API contribution rules and ADR expectations. With that work done, the team will now review existing PRs based on those updates.

Please note that, based on the updated standards described here:
https://devdocs.prestashop-project.org/9/admin-api/contribute-to-core-api/

some aspects of this PR currently do not meet the requirements. For this reason, I've added the Invalid label for now.

Someone from the team will take a closer look at the PR and provide concrete suggestions on how it can be adjusted to align with the new guidelines.

Thanks for your patience. Feedback will follow directly on the PR.

[Codencode]

Hello @kpodemski,
ok, no problem. I've noticed there have been some changes in this area, and I believe this can only improve the entire ecosystem — having clear rules to follow is always better 😉!
I remain at your disposal.

Thanks!