we have to pass in the ID of the title (ex. 60003959). Yet for all other API calls any reference to a movie in title_refs is made using the unique url id (ex. http://api.netflix.com/catalog/titles/movies/60003959)
Armando, I somewhat agree with you. In any case there is confusion that needs to be addressed.
For the URLs you note above, I don't think about passing IDs to them- the whole string is the ID. Each URL is an opaque resource reference in its own right. This is consistent in the rest of the API for resources that return title IDs- they are fully qualified URLs not just the numeric portion.
However, the prototypes we've shown in the API documentation make this confusing, since the numeric portion(s) are <something>ID. We'll be changing the docs to show example URLs instead of these confusing prototypes. Hopefully that will eliminate the confusion.
For example. If you use the APIs
catalog/titles/movies/movieID
catalog/titles/series/seriesID
catalog/titles/series/seriesID/seasons
catalog/titles/programs/programID
catalog/titles/discs/discID
we have to pass in the ID of the title (ex. 60003959). Yet for all other API calls any reference to a movie in title_refs is made using the unique url id (ex. http://api.netflix.com/catalog/titles/movies/60003959)
Armando Padilla
Message edited by Armando Padilla 3 years ago
Michael Hart – 3 years ago
Armando, I somewhat agree with you. In any case there is confusion that needs to be addressed.
For the URLs you note above, I don't think about passing IDs to them- the whole string is the ID. Each URL is an opaque resource reference in its own right. This is consistent in the rest of the API for resources that return title IDs- they are fully qualified URLs not just the numeric portion.
However, the prototypes we've shown in the API documentation make this confusing, since the numeric portion(s) are <something>ID. We'll be changing the docs to show example URLs instead of these confusing prototypes. Hopefully that will eliminate the confusion.