11–14 of 14 posts
Well I for one hope they put all of their API code up on github so the community can contribute to it. Just have to say, google's youtube api v3 is absolutely awful compared to the delightfully restful API of Github or Twitter.
Well I for one hope they put all of their API code up on github so the community can contribute to it. Just have to say, google's youtube api v3 is absolutely awful compared to the delightfully restful API of Github or Twitter.
What specifically are the issues with the YouTube API?
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.
Earlier quoted context omitted.
What specifically are the issues with the YouTube API?
In particular, they aren't restful or intuitive. If you've never used youtube's api v3, and someone demanded you give a basic explanation of what youtube data should look like, you'd guess: 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/chan…
api/v3/channels/teamcoco vs api/v3/channels?forUsername=teamcoco
api/v3/playlists/coco-uploads vs api/v3/playlist?id=whatever
api/v3/playlists/coco-uploads/videos vs api/v3/playlistItem?forChannel=whatever
The only thing that takes a second to understand is parts=id,snippet,topicDetails,contentDetails but seems really convenient optimize your rate limit usage based on the info you actually need.
Earlier quoted context omitted.
What specifically are the issues with the YouTube API?
In particular, they aren't restful or intuitive. If you've never used youtube's api v3, and someone demanded you give a basic explanation of what youtube data should look like, you'd guess: 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/chan…