Design¶
I’m a friend of well-structured / conclusive code and intuitive usage. So I tried to design the library in such way by
- JSON deserialization into objects instead of Strings for more out-of-the-box functionalities,
- combining similar JSON structures and reduce nested objects as much as possible to lighten the library and
- ensuring intuitive and natural workflow by - for example - returning lists directly.
Naming conventions¶
Some data retrieved from the API isn’t immediately apparent in my opinion - for example iso_639_1but you won’t probably think of it as the language tag on your first spot.
So I named such data fields into more human language and also some query parameters:
| TMDb field / query parameter | Named in this library | Example |
|---|---|---|
iso_639_1 |
languageCode |
de (German) |
iso_3166_1 |
countryCode |
DE (Germany) |
language |
language |
de or de-DE (German / Germany) |
region |
languageCode |
de (German) |
Response restructuring¶
Some API endpoints return data which is related to the language/country code (for example movie release
dates). Instead of returning a new object class the call returns a Map<String, List<T> for example
where the key is language / country code.