A few unusual aspects in the API content which I consider "strange"

To Developers: @CS-Cart_team
Here is a resulting API GET http://host/api/2.0/features/500:

An empty feature (variants) list:

{
“feature_id”: “500”,
“feature_code”: “”,
“company_id”: “1”,
“feature_type”: “S”,
“parent_id”: “0”,
“description”: “Color ChipType 0”,
“internal_name”: “Color ChipType 0”,
“lang_code”: “jp”,
“status”: “A”,
“position”: “0”,
“purpose”: “group_variation_catalog_item”,
“feature_style”: “dropdown_images”,
“filter_style”: “checkbox”,
“variants”: []
}

A feature (variants) list (sa list above) that contains two variants:

{
“feature_id”: “500”,
“feature_code”: “”,
“company_id”: “1”,
“feature_type”: “S”,
“parent_id”: “0”,
“description”: “Color ChipType 0”,
“internal_name”: “Color ChipType 0”,
“lang_code”: “jp”,
“status”: “A”,
“position”: “0”,
“purpose”: “group_variation_catalog_item”,
“feature_style”: “dropdown_images”,
“filter_style”: “checkbox”,
“variants”: {
“1970”: {
“variant_id”: “1970”,
“variant”: “00 WHITE”,
“lang_code”: “jp”,
“feature_id”: “500”,
“position”: “0”
},
“1971”: {
“variant_id”: “1971”,
“variant”: “01 WHITE”,
“lang_code”: “jp”,
“feature_id”: “500”,
“position”: “1”
}
}
}

Variants object structure: Those two JSON objects themselves are valid. However, in the second example, the “variants” field is an object, with variant IDs as keys. This structure is not wrong, but it might make iterating over the variants a bit (?) more complex. A common practice is to use an array of objects for such cases. My question is: WHY?

Well, the question “why” is rather rhetorical. Advise me how I can quickly fix part of the code so that subsequent updates do not break anything after the update.

I guess this is just the standard CS-Cart assumed when creating API, since this concept (using objects instead of arrays) is used in some other places. For example, product reviews and product images are also in objects, when you’re pulling data about products.

I’m not sure if I understand your question though - what do you want to fix in your code? If feature variants are stored in objects, build your code around it. I don’t think CS-Cart is going to change this without giving a huge warning before.

1 Like

To put it simply, for what reason sometimes variants can be an object, and sometimes an array? Weather conditions? Developers should have finally decided - is it an object or an array.

the concept? Could you elaborate on this concept, please? At the moment it looks like a kinda bug.

That was my question - how can I directly change the code myself, so as not to wait for the developers to figure out how to deal with it.

API versioning is widely used for this… 2.0.1, 2.0.2… coupled with other techniques, this adds value to the product, doesn’t it?

This is the default behavior of the json_encode standard PHP function:

You can modify the \Tygh\Api\Formats\Json::encode (app/Tygh/Api/Formats/Json.php) method and add the second parameter JSON_FORCE_OBJECT to json_encode if you wish to have the same output in both conditions, so it should look like this in the result:

    public function encode($data)
    {
        return json_encode($data, JSON_FORCE_OBJECT);
    }

I hope it will help you.

Hi. Thanks for replying.
Once a new update is released, will the file I changed be replaced with a file from the distribution?

In case the upgrade will contain any changes in this file, it will be replaced by the file from the upgrade. Otherwise - no.