First Experience with the Google+ API
So, Google released an API for Google+. Sort of. It only has three methods – People.get, Activities.list and Activities.get. But let’s assume we can build something with this. Not something useful, but…something.
So I decided to implement two features of my startup (http://welshare.com) – a chart with your posts, replies and +1s per day, and a list of your top recent messages. The API looked sufficient. Since I’m using Java, I grabbed the starter java project. First, the jar with the API classes (+ the ones generated from json) are in a jar that is not available in maven. It is available only in the example project. And the example uses jsp scriptlets. OK, fine. Then I had to authenticate. OAuth2 looks simple, but the classes in the standard google-api-client jar look suspicious. Lots of direct field access (deprecated now), some duplicating fields. OK, this is not the only OAuth2 implementation, so I used the one of spring-social. Worked fine.
So, now I have an access token, a refresh token. I implemented the charts and top messages features rather quickly, tested it with my account, it worked fine, and I deployed it.
But then other people tried the features and it wasn’t quite working for them – nothing in the “top messages”, and no +1s on the chart. Why is that? Well, it appears there’s a bug – not in welshare, but in Google+ – when you request user activities and pass the maxResults parameter, the plusoners.totalItems field is always 0. OK, you have a bug in your 3 methods that we waited 3 months for. But that’s beta, so it’s forgiven, and I head to their developers site to report the bug. Um, no. There is no place to report bugs. Something that developers were invited to do. Hm, perhaps I’ll see it when I authenticate? Oops, Internal Server Error. 2nd try – success, but still no bug reporting. Perhaps the discussion forum? I’ll try there. Waiting for moderator to approve my post. (Update: it appears there is an issue tracker – a link was given in a response to my report – http://code.google.com/p/google-plus-platform/issues/detail?id=4. And it seems the issue is already reported, 5 days ago.)
Overall experience – bad. Not enough effort for the Java (and perhaps the other) API clients (they should have versions, be a separate project, and be documented), no visible way to report bugs and bugs that should have been caught by QA/automation. On the plus side – the coding to the API itself was rather quick and without any issues.
Now, this post shouldn’t be viewed as whining. I’m trying to point out that Google will find it hard to win users and developers on their side if the experience is bad.
So, Google released an API for Google+. Sort of. It only has three methods – People.get, Activities.list and Activities.get. But let’s assume we can build something with this. Not something useful, but…something.
So I decided to implement two features of my startup (http://welshare.com) – a chart with your posts, replies and +1s per day, and a list of your top recent messages. The API looked sufficient. Since I’m using Java, I grabbed the starter java project. First, the jar with the API classes (+ the ones generated from json) are in a jar that is not available in maven. It is available only in the example project. And the example uses jsp scriptlets. OK, fine. Then I had to authenticate. OAuth2 looks simple, but the classes in the standard google-api-client jar look suspicious. Lots of direct field access (deprecated now), some duplicating fields. OK, this is not the only OAuth2 implementation, so I used the one of spring-social. Worked fine.
So, now I have an access token, a refresh token. I implemented the charts and top messages features rather quickly, tested it with my account, it worked fine, and I deployed it.
But then other people tried the features and it wasn’t quite working for them – nothing in the “top messages”, and no +1s on the chart. Why is that? Well, it appears there’s a bug – not in welshare, but in Google+ – when you request user activities and pass the maxResults parameter, the plusoners.totalItems field is always 0. OK, you have a bug in your 3 methods that we waited 3 months for. But that’s beta, so it’s forgiven, and I head to their developers site to report the bug. Um, no. There is no place to report bugs. Something that developers were invited to do. Hm, perhaps I’ll see it when I authenticate? Oops, Internal Server Error. 2nd try – success, but still no bug reporting. Perhaps the discussion forum? I’ll try there. Waiting for moderator to approve my post. (Update: it appears there is an issue tracker – a link was given in a response to my report – http://code.google.com/p/google-plus-platform/issues/detail?id=4. And it seems the issue is already reported, 5 days ago.)
Overall experience – bad. Not enough effort for the Java (and perhaps the other) API clients (they should have versions, be a separate project, and be documented), no visible way to report bugs and bugs that should have been caught by QA/automation. On the plus side – the coding to the API itself was rather quick and without any issues.
Now, this post shouldn’t be viewed as whining. I’m trying to point out that Google will find it hard to win users and developers on their side if the experience is bad.
Hey, I wish you good luck with the server side. I wrote a java client for Google Translator Toolkit. Just a prototype because GTT API was quite unstable (using 1.5-beta client now). And after a year, I still can’t use it at production. Don’t know what to do. For instance, when a translator mark the document as translated (which is a signal for client to retrieve the document) the field PercentComplete just doesn’t reflect what Toolkit itself shows – 100%. Also response with Feed of all documents/entries, absolutelly doesn’t correspond to documents listed in GTT …. http://goo.gl/3HaHv ….They also made it restricted and my soft currently relies on it…I’m quite stuck because of it…Anyway, I hope I will try the client of yours in future. Cheers
All back with our Stellar Lifetime Warranty that’s transferable from builders to home-owners.
This is especially important if you are handing over one of the paint brushes to your kid.
The expense of the wifi doorbell furthermore is dependent
upon the particular certain characteristic
with all the wi-fi doorbell since it really is different coming
from 1 entrance bell about the distinct additional.