Provide information about product value type in product response

[testowyludek1234]

At the moment product values return something along the lines

{
        "name": [
          {
            "data": "Top",
            "locale": "en_US",
            "scope": null
          },
          {
            "data": "Débardeur",
            "locale": "fr_FR",
            "scope": null
          }
}

However data field contains strings with different meanings (text, number, date, path, identifier) as well as arrays of string or object with two fields (metrics, price). This make it hard to write deserializers in statically-typed languages, so the proposal is to add attribute_code field to this response. This will let the deserializer to know type upfront and dispatch deserialization processing to given subtype like here: https://www.baeldung.com/jackson-inheritance#2-per-class-annotations

[ajmnz]

You can more or less achieve this by first fetching all attributes (which include the type, localizable, scopable, etc.) and then mapping the response to each attribute code. Of course, it's more costly to do it this way and including it in the product value itself would be much easier.

https://api.akeneo.com/api-reference.html#get_attributes__code_

[testowyludek1234]

I'm aware of this workaround however I'm writing library which can be described as Akeneo client for API in Java. It makes more sense for it to have stateless architecture. With this workaround however state must be kept inside client and there are no guarantees that between two calls attribute definition hasn't changed (someone deleted and recreated attribute from UI). Attributes can also appear or disappear - bottom line is you will have to make a call for all attributes every time you make a call for product to be 100% sure.

From what I can see there was a "similar" change (https://api.akeneo.com/concepts/products.html#the-linked_data-format) made in regard to attribute options, that codes started to be available in response in linked_data.

I'm still proposing to add this as it will be useful for bunch of scenarios, simple "attribute_type": "pim_catalog_text" etc. on the same level as "data" would suffice. It will be a little redundant but that will make response compatible backwards for time being.