Changes

A related question is how languages should be encoded in a resulting json. For each language dependent field the corresponding language must be known. There are three options:

A related question is how languages should be encoded in a resulting json. For each language dependent field the corresponding language must be known. There are three options:

# Adapt field names - add a postfix to a field name to indicate the language, i.e. name_fr. Draw back of this approach is that the relevant postfixes are not known before hand. A list of possible languages in the json circumvents this. However this requires more extensive programming for the api user. (This approach is currently used).

# Adapt field names - add a postfix to a field name to indicate the language, i.e. name_fr. Draw back of this approach is that the relevant postfixes are not known before hand. A list of possible languages in the json circumvents this. However this requires more extensive programming for the api user. (This approach is currently used).

# Simple dictionary - encode a language dependent fields as a dictionary, i.e { "en":"in english", "fr":"en français"}. This keeps the drawback that the fieldnames are not known before hand;

# Simple dictionary - encode a language dependent fields as a dictionary, i.e { "en":"in english", "fr":"en français"}. This keeps the drawback that the field names are not known before hand;

# Structured dictionary - any field that can be in a specific language can be encoded as a standard "language" dictionary: { {"languageCode":"en", "languageValue":"in english"}, {"languageCode":"fr", "languageValue":"en français"}

# Structured dictionary - any field that can be in a specific language can be encoded as a standard "language" dictionary: { {"languageCode":"en", "languageValue":"in english"}, {"languageCode":"fr", "languageValue":"en français"}

This is also valid for fields that will be in the interface language, as a translation is not always available.

This is also valid for fields that will be in the interface language, as a translation is not always available.

=== comments ===

=== comments ===

* The json seems to have two user groups: OFF itself and end users (apps). Can the json be split in two section that correspond to these groups as well? Not sure whether this is a good approach.

* The json seems to have two user groups: OFF itself and end users (apps). Can the json be split in two section that correspond to these groups as well? Not sure whether this is a good approach.

* The json can be more structured, so that it is more readible for a viewer, but also from an parsing interpreting point of view. I.e. everything that corresponds to packaging goes together.

* The json can be more structured, so that it is more readable for a viewer, but also from an parsing interpreting point of view. I.e. everything that corresponds to packaging goes together.

* Improved field-names, which clearly reflect the origin or processing of the data. This should reduce the number of questions around field s and their interpretation.

* Improved field-names, which clearly reflect the origin or processing of the data. This should reduce the number of questions around field s and their interpretation.

* version 1 of the api used a language code suffix (i.e. ''_en''), to indicate the language used for the strings. Which language codes should be looked at, depended on the content of the json itself. This implied that the field names needed to be constructed, adding extra complexity to the json decoder. Another solution is to use a dictionary to encode these strings like { "languageCode" : "en", "string": "stringValue }.

* version 1 of the api used a language code suffix (i.e. ''_en''), to indicate the language used for the strings. Which language codes should be looked at, depended on the content of the json itself. This implied that the field names needed to be constructed, adding extra complexity to the json decoder. Another solution is to use a dictionary to encode these strings like { "languageCode" : "en", "string": "stringValue }.

= Robotoff write API =

= Robotoff write API =

This api allows to write reponses to insight questions provided by the Robotoff read API.

This api allows to write responses to insight questions provided by the Robotoff read API.

= Search API =

= Search API =

* See [[Open Food Facts Search API Version 2]]

* See [[Open Food Facts Search API Version 2]]