Right now the former two just return a string, while the later returns an array of string. (The former two 404 on no such term, discuss in #14.)
Sometimes it might be useful to have the requested language code as well, and if language fallback is done, then the resulting language might also be needed. Something like the below can easily be done, though makes usage where this info is not needed slightly more difficult:
For aliases the difference is even bigger, as making each element of the array be such a map is quite a bit of bloat for those who don't need it. If language fallback support is declared as out of scope for these endpoints, then the aliases case could include the language more reasonably as follows:
{
"language": "en",
"aliases": [ "foo", "bar" ]
}
Is having a language code in there really useful to begin with, and is there reason to not just return it as a response header?
Right now the former two just return a string, while the later returns an array of string. (The former two 404 on no such term, discuss in #14.)
Sometimes it might be useful to have the requested language code as well, and if language fallback is done, then the resulting language might also be needed. Something like the below can easily be done, though makes usage where this info is not needed slightly more difficult:
For aliases the difference is even bigger, as making each element of the array be such a map is quite a bit of bloat for those who don't need it. If language fallback support is declared as out of scope for these endpoints, then the aliases case could include the language more reasonably as follows:
Is having a language code in there really useful to begin with, and is there reason to not just return it as a response header?