Change Details

A number of minor, but annoying, inconsistencies can be observed in what version 1 of our API currently returns. This task keeps track of the need of fixing all of them. Here is a WIP list: - the field "date" is sometimes a second-since-epoch floating point timestamp ([[ https://archive.softwareheritage.org/api/1/origin/1/visits/ | example ]], [[ https://archive.softwareheritage.org/api/1/origin/1/visit/11/ | example ]]), and other a textual ISO 8601 timestamp ([[ https://archive.softwareheritage.org/api/1/release/7045404f3d1c54e6473c71bbb716529fbad4be24/ | example ]]). As a general rule, we should strive to always return the same type for the same dictionary key - the "revision" endpoint uses two separate lists for listing the parent commits: "parents", and "parents_url" ([[ https://archive.softwareheritage.org/api/1/revision/6072557b6c10cd9a21145781e26ad1f978ed14b9/ | example ]]). This makes it annoying to use and does not structurally guarantee well-formendess (e.g., the two lists can have different length). We should use a single list of dicts

A number of minor, but annoying, inconsistencies can be observed in what version 1 of our API currently returns. This task keeps track of the need of fixing all of them. Here is a WIP list: - the field "date" is sometimes a second-since-epoch floating point timestamp ([[ https://archive.softwareheritage.org/api/1/origin/1/visits/ | example ]], [[ https://archive.softwareheritage.org/api/1/origin/1/visit/11/ | example ]]), and other a textual ISO 8601 timestamp ([[ https://archive.softwareheritage.org/api/1/release/7045404f3d1c54e6473c71bbb716529fbad4be24/ | example ]]). As a general rule, we should strive to always return the same type for the same dictionary key - the "revision" endpoint uses two separate lists for listing the parent commits: "parents", and "parents_url" ([[ https://archive.softwareheritage.org/api/1/revision/6072557b6c10cd9a21145781e26ad1f978ed14b9/ | example ]]). This makes it annoying to use and does not structurally guarantee well-formendess (e.g., the two lists can have different length). We should use a single list of dicts - the "release" and "revision" endpoints are inconsistent on how they indicate the author: revision as "author" + "author_url", while "release" has only "author" and no "author_url"

A number of minor, but annoying, inconsistencies can be observed in what version 1 of our API currently returns. This task keeps track of the need of fixing all of them. Here is a WIP list: - the field "date" is sometimes a second-since-epoch floating point timestamp ([[ https://archive.softwareheritage.org/api/1/origin/1/visits/ | example ]], [[ https://archive.softwareheritage.org/api/1/origin/1/visit/11/ | example ]]), and other a textual ISO 8601 timestamp ([[ https://archive.softwareheritage.org/api/1/release/7045404f3d1c54e6473c71bbb716529fbad4be24/ | example ]]). As a general rule, we should strive to always return the same type for the same dictionary key - the "revision" endpoint uses two separate lists for listing the parent commits: "parents", and "parents_url" ([[ https://archive.softwareheritage.org/api/1/revision/6072557b6c10cd9a21145781e26ad1f978ed14b9/ | example ]]). This makes it annoying to use and does not structurally guarantee well-formendess (e.g., the two lists can have different length). We should use a single list of dicts - the "release" and "revision" endpoints are inconsistent on how they indicate the author: revision as "author" + "author_url", while "release" has only "author" and no "author_url"