I wonder where the data was coming from.
There was a small blip of outrage at the time but nothing major.
http://thenextweb.com/google/2012/08/28/did-google-just-quie...
1. a user has many (or has one) channels 2. a channel has many playlists 3. a playlist has many videos
So naturally, you'd expect the following:
1. api/v3/channels/teamcoco -> gets you the channel with id "teamcoco" 2. api/v3/channels/teamcoco/playlists -> gets you all the playlists on teamcoco's channel. Say they have ids [coco-001, coco-002, coco-uploads, ...] 3. api/v3/playlists/coco-uploads -> should get you the playlist with id "coco-uploads" 4. api/v3/playlists/coco-uploads/videos -> should get you the videos belonging to playlist id "coco-uploads"
Of course, the real api/v3 has none of that. The full details you'll have to read at the developer console at google, but in rough summary, if you wanted the teamcoco channel, you'd do:
1. api/v3/channels?forUsername=teamcoco&parts=id,snippet,topicDetails,contentDetails&fields=([forgot-what-went-here])
And you'd get a json that looks like: { ... items: [...], ... }
and all 1 channel with id "teamcoco" will be in items, with playlist info strewn somewhere in topicDetails or contentDetails. Then, when you want playlist information, you have to look at either the /playlist?id=whatever or /playlistItem?forChannel=whatever, depending on whether you wanted playlist metadata or playlist video data.
In all, it's an extremely horrible user experience, and yes, I get it, Google has to split up the data model so youtube can scale. Sure, but then they go about and expose all the details of their implementation in their external developer facing API. And if you've ever worked with other such api that has their innards exposed for the outside world to see, you know to be antsy. Such trashy api is bound to be refactored as soon another "Rockstar" engineer gets hired, so say goodbye to whatever customized adapter/serializer you wind up writing for api/v3 4 months down the road.
