5 ms·

Google APIs Repository on GitHub

64 points by wora 12y ago

knd775 12y ago
This is pretty cool. Right now, there is very little there, but hopefully more will get put up. I've been working with maps a lot recently, and this would be extremely useful if maps were there.
- wora 12y ago
  As more Google APIs support gRPC, their API definitions will be published.
JoshGlazebrook 12y ago
I'm still bitter over the shutdown of the "hidden" weather api. I know it wasn't official but come on...
- markdown 12y ago
  Not sure if sarcasm, or extreme sense of entitlement.
- ryannevius 12y ago
  Google had its own weather API? Well, I missed out. I wonder where the data was coming from.
  - JoshGlazebrook 12y ago
    I believe it was something that was used in the weather widget in iGoogle. There was a small blip of outrage at the time but nothing major. http://thenextweb.com/google/2012/08/28/did-google-just-quietly-kill-private-weather-api/ http://thenextweb.com/google/2012/08/28/did-google-just-quie...
tristanz 12y ago
Are there any more details on how Google is designing these new API endpoints? The information here is pretty sparse. It seems like a big strategic initiative to unify API design though.
ffn 12y ago
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.
- abraham 12y ago
  What specifically are the issues with the YouTube API?
  - ffn 12y ago
    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/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.
jfroma 12y ago
I wonder if they use the protocol buffers definition to validate json over http, or they dupe schemas into json schemas or other format.

64 points by wora 12y ago

This is pretty cool. Right now, there is very little there, but hopefully more will get put up. I've been working with maps a lot recently, and this would be extremely useful if maps were there.

wora 12y ago
As more Google APIs support gRPC, their API definitions will be published.

JoshGlazebrook 12y ago

I'm still bitter over the shutdown of the "hidden" weather api. I know it wasn't official but come on...

markdown 12y ago
Not sure if sarcasm, or extreme sense of entitlement.
ryannevius 12y ago
Google had its own weather API? Well, I missed out. I wonder where the data was coming from.
- JoshGlazebrook 12y ago
  I believe it was something that was used in the weather widget in iGoogle. There was a small blip of outrage at the time but nothing major. http://thenextweb.com/google/2012/08/28/did-google-just-quietly-kill-private-weather-api/ http://thenextweb.com/google/2012/08/28/did-google-just-quie...

tristanz 12y ago

Are there any more details on how Google is designing these new API endpoints? The information here is pretty sparse. It seems like a big strategic initiative to unify API design though.

ffn 12y ago

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.

abraham 12y ago
What specifically are the issues with the YouTube API?
- ffn 12y ago
  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/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.

jfroma 12y ago

I wonder if they use the protocol buffers definition to validate json over http, or they dupe schemas into json schemas or other format.