TUM-Dev/eat-api

Do not mix types in JSON files

COM8 opened this issue · 4 comments

COM8 commented

The base_price can either be a string or double depending on whether we have found a valid price for the dish or not.
This leads to problems when we do automated parsing of those files.

Here the solution would be to use either null or -1 in case we did not find any price for the dish.

Examples

"prices": {
    "students": {
        "base_price": "N/A",
        "price_per_unit": null,
        "unit": null
    },
    "staff": {
        "base_price": "N/A",
        "price_per_unit": null,
        "unit": null
    },
    "guests": {
        "base_price": "N/A",
        "price_per_unit": null,
        "unit": null
    }
}

https://tum-dev.github.io/eat-api/mensa-arcisstr/2021/28.json

"prices": {
    "students": {
        "base_price": 0.0,
        "price_per_unit": 0.33,
        "unit": "100g"
    },
    "staff": {
        "base_price": 0.0,
        "price_per_unit": 0.55,
        "unit": "100g"
    },
    "guests": {
        "base_price": 0.0,
        "price_per_unit": 0.66,
        "unit": "100g"
    }
}

https://tum-dev.github.io/eat-api/mensa-garching/2021/28.json

COM8 commented

Depending on how we solve this, other projects relying on this API have to adopt this (breaking?) change.
Perhaps we can create PRs for them.

joschahenningsen commented

Semantically null makes sense but not all languages allow null in primitives so I'm fine with -1 as well. Is there a list of projects using the eat-api? I could take care of the android app.

I assume the changes will only apply to future prices and the existing ones will stay as they are?

COM8 commented

Yes, it will apply only to further prices.
Here is a list: https://github.com/TUM-Dev/eat-api#projects-using-eat-api

I probably will have some time next week to fix this.