The official Google Code blog

Author Photo
By Nam Nguyen, Software Engineer

Last year we added image results to Google Custom Search Engines to enable sites to offer image-only results that showcase photos and other digital images. For site owners who want more flexibility in presentation, they are also now available from the Custom Search API.

Read more about accessing Image Results from the Custom Search API or try it out in the Custom Search API Explorer. For billing purposes, image queries will be treated the same as web queries. If you are still using the deprecated Google Image Search API, now’s a great time to switch!

Below is an example of an image search to find small jpeg images of flowers:

https://www.googleapis.com/customsearch/v1?key=YOUR_API_KEY&cx=YOUR_CSE_ID&q=flower&searchType=image&fileType=jpg&imgSize=small&alt=json

With a valid key and cse id, here is a possible json result returned for an image item:

{
 "kind": "customsearch#result",
 "title": "flower-photo",
 "htmlTitle": "\u003cb\u003eflower\u003c/b\u003e-photo",
 "link": "http://images.example.com/flowerphoto.jpg",
 "displayLink": "images.example.com",
 "snippet": "photo of flower",
 "htmlSnippet": "photo of \u003cb\u003eflower\u003c/b\u003e",
 "mime": "image/jpeg",
 "image": {
 "contextLink": "http://images.example.com/flowergallery.html",
 "height": 100,
 "width": 100,
 "byteSize": 6104,
 "thumbnailLink": "https://encrypted-tbn2.google.com/images?q=tbn:3x4MPL3",
 "thumbnailHeight": 82,
 "thumbnailWidth": 82
 }
}

which you can use to render the image in your own site.

Note that you need to enable image search in your custom search engine control panel for the custom image search to work.


Nam Nguyen works on the JSON/Atom Custom Search API, which lets developers retrieve and display results from Google Custom Search programmatically. He is dedicated to making developers' lives a little easier by providing a simple API.

Posted by Scott Knaster, Editor

Author Photo
By Navneet Joneja, Product Manager

Google Cloud Storage is a robust, high-performance service that enables developers and businesses to use Google’s infrastructure to store and serve their data. Today, we’re announcing a new feature that gives you greater control over concurrent writes to the same object, and the availability of an App Engine Files API that makes it easier to read and write data from Java App Engine applications.

Write concurrency control

A number of our customers have asked us for greater control over concurrent writes, in order to implement features like strongly consistent write operations and distributed locking semantics in the cloud. In response to your feedback, we’re announcing the release of version-based concurrency control. Every time you update an object, it gets assigned a 32-bit, monotonically increasing sequence number. This version number is returned as a header with every GET or HEAD request. You can then use a conditional write operation to manage concurrent updates to the object (for example, when you want read-modify-write semantics). This feature is currently experimental.

AppEngine Files API for Java applications

Last fall, we announced the ability to read and write your Google Cloud Storage data using the App Engine Files API for Python applications. Today, we’re making the Files API available to Java App Engine applications too. This feature is currently experimental, and we’ll continue to enhance it in the months to come.

As always, we welcome your feedback in our discussion group. If you haven’t tried Google Cloud Storage yet, you can sign up and get started here.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious almost-two-year-old.

Posted by Scott Knaster, Editor

Author Photo
By Scott Knaster, Google Code Blog Editor

This is the last Fridaygram of 2011, and like most everybody else, we’re in a reflective mood. It’s also the 208th post on Google Code Blog this year, which means we’ve averaged more than one post every two days, so that’s plenty of stuff for you to read. What did we write about?

At Google, we love to launch. Many of our posts were about new APIs and client libraries. We also posted a bunch of times about HTML5 and Chrome and about making the web faster. And we posted about Android, Google+, and Google Apps developer news.

Many of our 2011 posts were about the steady progress of App Engine, Cloud Storage, and other cloud topics for developers. We also published several times about commerce and in-app payments.

2011 was a stellar year for Google I/O and other developer events around the world. Some of our most popular posts provided announcements, details, and recaps of these events. And we welcomed a couple dozen guest posts during Google I/O from developers with cool stories to tell.

The two most popular Code Blog posts of the year were both launches: the Dart preview in October, and the Swiffy launch in June.

Last, and surely least, I posted 26 Fridaygrams in an attempt to amuse and enlighten you. Thank you for reading those, and thanks for dropping by and reading all the posts we’ve thrown your way this year. See you in 2012!

And finally, please enjoy one more Easter egg.

Author Photo
By Marc Cohen, Developer Relations

This holiday season, the Google Prediction API Team is bringing you four presents and, thanks to the joys of cloud computing, no reindeer are required for delivery. Here’s what you’ve already received:

• Faster on-ramp: We’ve made it easier to get started by enabling you to create an empty model (by sending a trainedmodels.insert request with no storageDataLocation specified) and add training data using the trainedmodels.update method. This change allows you to submit your model contents without needing to stage the data in Google Cloud Storage.
• Improved updates: The algorithms used to implement model updates (adding additional data to existing models) have been modified to work faster than ever.
• More classification algorithms: We’ve increased the number of classification algorithms used to build predictive models, resulting in across-the-board improvements in accuracy.
• Integration with Google Apps Script: Prediction services are now available as part of Google Apps Script, which means you can integrate prediction services with Google Docs, Google Maps, Gmail, and other great Google products.

All of the above enhancements are supported by the current Prediction API version 1.4 so you can enjoy these features using the existing client libraries.

Happy Holidays from the Google Prediction API Team. We’re looking forward to bringing you more exciting features in 2012!


Marc Cohen is a member of Google’s Developer Relations Team in Seattle. When not teaching Python programming and listening to indie rock music, he enjoys using the Google Prediction API to peer into the future.

Posted by Scott Knaster, Editor

Author Photo
By Ali Pasha, Google Affiliate Network Product Manager

Google Affiliate Network is a free program that makes it easy for website publishers to connect with quality advertisers and get rewarded for driving conversions.

Today we’re making it even easier for affiliates and advertisers to work with Google Affiliate Network by launching the Google Affiliate Network API, which enables publishers and advertisers to automate various tasks related to Google Affiliate Network.

For more information, please see the Google Affiliate Network blog.


Ali Pasha has been a Google Product Manager for several years and now works on Google Affiliate Network. Ali has also made key contributions to Android App Inventor, Google Code, Google Code Search, and Google AJAX APIs.

Posted by Scott Knaster, Editor

By Jeetendra Soneja and Nick Mihailovski, Google Analytics API Team

Today we are announcing the new Google Analytics Core Reporting API as a replacement for the Data Export API. This is the second phase in a larger project we started a couple months back to upgrade our APIs to new infrastructure.

The Core Reporting API has two versions.

Version 3.0 is a brand new API, with a 10x reduction in output size and support for many new client libraries, like PHP, Ruby, Python, JavaScript and Java. All new features will only be added to this version.

Version 2.4 is backward compatible with the legacy Data Export Version 2.3.

If you are building a new application or maintaining an existing one, we highly recommend migrating to version 3.0.

One of the biggest changes in switching to the Core Reporting API is that you now need to register your applications via the Google APIs Console and use a project ID to access the API.

With this change, we are also announcing the deprecation of the Data Export API version 2.3. This API will continue to work for 6 months, after which all v2.3 XML requests will return a v2.4 response. Also, we plan to terminate the Data Export API Account Feed. All configuration data should be retrieved through the Google Analytics Management API.

See our Data Export API changelog for all the details of the change and read our developer documentation for more details about each API.

If you have any questions feel free to reach out in our Data Export API Google group.


Jeetendra Soneja is the technical engineering lead on the Google Analytics API team. He's a big fan of cricket – the game, that is. :)

Nick Mihailovski is a Senior Developer Programs Engineer working on the Google Analytics API. In his spare time he likes to travel around the world.

Posted by Scott Knaster, Editor

By Brendan O’Brien and Antonio Fuentes, Google Developer Team

Today we reached another milestone in our efforts to provide infrastructure and tools to make it easier for developers to use Google APIs: we have released the Google APIs Client Library for JavaScript in Alpha. This client library is the latest addition to our suite of client libraries, which already includes Python, PHP, and Java.

This compact and efficient client library provides access to all the Google APIs that are listed in the APIs Explorer. The client library is also flexible, supporting multiple browser environments including Chrome 8+, Firefox 3.5+, Internet Explorer 8+, Safari 4+, and Opera 11+. In addition, the JavaScript client library supports OAuth 2.0 authorization methods.

You can load the client library using the following script tag:

<script src="https://apis.google.com/js/client.js?onload=CALLBACK"></script>

Loading an API and making a request is as easy as executing:

gapi.client.load('API_NAME', 'API_VERSION', CALLBACK);

// Returns a request object which can then be executed.
// METHOD_NAME is only available once CALLBACK runs.

var request = gapi.client.METHOD_NAME(PARAMETERS_OBJECT); 
request.execute(callback);

You can use the APIs Explorer to check all the methods available for an API, as well as the parameters for each method. For instance, use the above syntax with the plus.activities.search method of the Google+ API to query activities:

<!DOCTYPE html>
<html>
 <head>
 </head>

 <body>
  <script type="text/javascript">

function init() {

 // Load your API key from the Developer Console
 gapi.client.setApiKey('YOUR_API_KEY');

 // Load the API
 gapi.client.load('plus', 'v1', function() {
   var request = gapi.client.plus.activities.search({
     'query': 'Google+',
      'orderby': 'best'
      });

   request.execute(function(resp) {
     // Output title
     var heading = document.createElement('h4');
     heading.appendChild(document.createTextNode(
 resp.title));
     var content = document.getElementById('content');
     content.appendChild(heading);

     // Output content of the response
     if (!resp.items) {
      content.appendChild(document.createTextNode(
 'No results found.'));
     } else {
      for (var i = 0; i < resp.items.length; i++) {
       var entry = document.createElement('p');
      entry.appendChild(document.createTextNode(
 resp.items[i].title));
       content.appendChild(entry);
      }
     }
    });
  });
 }
  </script>
  <script src="https://apis.google.com/js/client.js?onload=init"></script>

  <div id="content"></div>
 </body>
</html>

To try this yourself, sign up in the Google APIs console or refer to the documentation on acquiring and using a developer key in the Google+ API.

The Google APIs Client Library for JavaScript is currently in Alpha, which means that we are actively developing it, but wanted to get the library in your hands as soon as possible, and we welcome any feedback to make the code better. While you can use the current library to start writing code, you should use caution when writing production code as library code changes may break your application. We are working hard to upgrade this release to Beta and beyond soon, and to release even more client libraries.

To get started, visit the JavaScript Client Library documentation page. We also welcome your feedback, which you can provide using the JavaScript client group.


Brendan O'Brien is a Software Engineer for the Browser Client group at Google. Prior to working on JavaScript APIs he was a frontend engineer for iGoogle. He is passionate about JavaScript and enjoys building web applications.

Antonio Fuentes is a Product Manager for the Google API Infrastructure group. He has experience launching products in the cloud computing, infrastructure, and virtualization space.

Posted by Scott Knaster, Editor

Author Photo
By Dan Holevoet, Developer Relations Team

A platform is more than the sum of its component parts. You can read about it or hear about it, but to really learn what makes up a platform you have to try it out for yourself, play with the parts, and discover what you can build.

With that in mind, we started a project called Au-to-do: a full sample application implementing a ticket tracker, built using Google APIs, that developers can download and dissect.


Au-to-do currently uses the following APIs and technologies:

• Google App Engine (with the Python runtime, Datastore API, and Task Queues API)
• Google Cloud Storage
• Google Prediction API
• Google Tasks API
• OAuth 2.0

Additional integrations with Google APIs are on their way. We are also planning a series of follow-up blog posts discussing each of the integrations in depth, with details on our design decisions and best practices you can use in your own projects.

By the way, if you’re wondering how to pronounce Au-to-do, you can say "auto-do" or "ought-to-do" — either is correct.

Ready to take a look at the code? Check out the getting started guide. Found a bug? Have a great idea for a feature or API integration? Let us know by filing a request.

Happy hacking!


Dan Holevoet joined the Google Developer Relations team in 2007. When not playing Starcraft, he works on Google Apps, with a focus on the Calendar and Contacts APIs. He's previously worked on iGoogle, OpenSocial, Gmail contextual gadgets, and the Google Apps Marketplace.

Posted by Scott Knaster, Editor

By Ion Constantinescu and Chris Cartland, APIs Console Team

It's been nearly one year since we launched the Google APIs Console to help you manage API usage across your sites and apps. We've had some great feedback about what you like (and don't), and are working hard every day to improve the overall experience. To this end, we want to highlight a number of recent enhancements.

Introducing v2 of the Google APIs Console Traffic Reports Page

The Google APIs Console contains a list of traffic reports that display information about how the APIs enabled per project are being used. Based on customer feedback, we've made a few enhancements:

• We have consolidated all API traffic in a single display.
• We now compare traffic between multiple APIs in a single project.
• We now show demographic and usage data about your API requests.

We believe we have made the Traffic Reports page cleaner and more compact without losing any functionality. We already have a list of enhancements we want to make to the page, and we would love to hear from you to help drive our prioritization.


Introducing the Google APIs Console Dashboard

You told us that you want to jump into a project's page and see more of a dashboard that describes what's happening on your project. You said you want to see which services are enabled, the availability of said services, general project administration, and a quick link to how much the project costs to run.


Our new Dashboard page is the first step in delivering on this experience. We will continue to enhance the Dashboard based on your collective feedback, so please take a look and let us know what you think.

New APIs Available in the Google APIs Console

We'd also like to announce some APIs are now available in the Console:

Web Fonts Developer API: this gives access to the metadata available for all families served by Google Web Fonts. You can create dynamic apps that can query Google Web Fonts and get an accurate list of the families currently available.

Google Orkut v2 REST API: this enables you to access select Orkut features. This API works like an extension of the JSON-RPC off-site application API, although it uses a different protocol.

Google Analytics Management API v3: this provides read-only access to Google Analytics configuration data. With the Management API you can list all the Account, Web Property and Profile information for a user, retrieve a Profile ID to use with the Data Export API, determine which goals are active and access their configured names, and retrieve a user's Custom Segments to apply them to Data Export API queries.

Blogger JSON API: this allows client applications to view and update Blogger content in the form of Google Data API feeds. Your client application can use the Blogger Data API to create new blog posts, edit and delete existing blog posts, and query for blog posts that match particular criteria.

We will continue to make changes and update our systems to make your development experience as great as possible. As always, if you have any questions, comments, or concerns, please contact us.


Ion Constantinescu is a Google Software Engineer working on the Google APIs Console. He has an academic background in Artificial Intelligence in the field of web service technologies.

Chris Cartland is a former Google Associate Product Manager Intern who worked on the Google APIs Console. He is currently helping CalSol - UC Berkeley's Solar Vehicle Team that designs and builds solar cars capable of racing at highway speeds - prepare to compete in the 2011 Veolia World Solar Challenge in Australia.


Posted by Scott Knaster, Editor

Author Photo
By Zachary Goldberg, Product Manager

Since the general availability launch of the Prediction API this year at Google I/O, we have been working hard to give every developer access to machine learning in the cloud to build smarter apps. We’ve also been working on adding new features, accuracy improvements, and feedback capability to the API. Today we take another step by announcing Prediction v1.4. With the launch of this version, Prediction is graduating from Google Code Labs, reflecting Google’s commitment to the API’s development and stability. Version 1.4 also includes two new features:

• Data Anomaly Analysis
• One of the hardest parts of building an accurate predictive model is gathering and curating a high quality data set. With Prediction v1.4, we are providing a feature to help you identify problems with your data that we notice during the training process. This feedback makes it easier to build accurate predictive models with proper data.
• PMML Import
• PMML has become the de facto industry standard for transmitting predictive models and model data between systems. As of v1.4, the Google Prediction API can programmatically accept your PMML for data transformations and preprocessing.
• The PMML spec is vast and covers many, many features. You can find more details about the specific features that the Google Prediction API supports here.

[フレーム]

We’re looking forward to seeing what you create with these new capabilities!

Feel free to find us and ask questions about these new features on our discussion group or submit feedback via our feedback form.


Zachary Goldberg is Product Manager for the Google Prediction API. He has a strange fascination with the Higgs Boson.

Posted by Scott Knaster, Editor

Author Photo
By Navneet Joneja, Product Manager for Google Cloud Storage

Google Storage for Developers is now out of Code Labs, and has a new name: Google Cloud Storage. In addition, we're also happy to announce some new features, and a significant price reduction.

App Engine File API Support

When we opened the service to all this summer, many of our customers asked for an easier way to use Google Cloud Storage with their App Engine applications. In response to your feedback, you can now read and write your data via the App Engine Files API, enabling you to quickly build your content management tools, data sharing applications, web games and more using the powerful combination of App Engine and Cloud Storage. This feature is experimental and currently Python-only, but we’re working on adding Java support and additional features.

Usage Information

We’re introducing a new API that gives you access to detailed usage information (including network access and storage use data). You can use this feature to analyze your usage, integrate with your analysis systems and build your own value-added applications using Google Cloud Storage. This feature is currently experimental.

Lower Prices

We're no longer charging for upload bandwidth into the Google cloud. In addition, we’re lowering our prices across the board and introducing volume discounts for our larger users. We are committed to offering an extremely high quality of service to all our customers. As the product has evolved, we’ve found ways to offer the same great service at a lower cost, so now our prices are lower too. For example, under our new prices, a customer storing a hundred terabytes of data, reading twenty terabytes and writing ten terabytes a month would pay approximately 40% less a month. The difference is even greater for customers with higher usage. Our new prices are retroactive to the beginning of October. Please see our updated pricing here.

As always, we welcome your feedback in our discussion group. If you haven’t yet tried Google Cloud Storage, you can sign up and get started here.


Navneet Joneja loves being at the forefront of the next generation of simple and reliable software infrastructure, the foundation on which next-generation technology is being built. When not working, he can usually be found dreaming up new ways to entertain his intensely curious one-year-old.

Posted by Scott Knaster, Editor

By Jordanna Chord , Software Engineer, Google+ API Team

Cross-posted with the Google+ Platform Blog

Thank you to all of you who tried out our first Google+ API release and let us know how you were using it. And thank you also to those of you who asked for more. In the spirit of releasing early and often, today we’ve released some of the new features that you requested.

Search for it

Last month we launched search in Google+, and now it’s available in the API. You can search for public posts using the new activities.search method by sending the following HTTP request:

GET 
https://www.googleapis.com/plus/v1/activities?query=cookie%20recipes&orderBy=best&key=[yourAPIKey]

This method searches across the body and comments of public posts. It returns the following JSON encoded output (excerpted for brevity):

{
 "kind": "plus#activityFeed",
 "title": "Plus Search for cookie recipes",
 "updated": "2011-09-30T16:57:34.479Z",
 "id": "tag:google.com,2010:buzz-search-feed:x4rIYTKpR7NZCL8Id8RHXQ",
 "items": [
 {
 "kind": "plus#activity",
 “id”: “123”,
 "title": "You have to try these out.",
 "object": {
 "objectType": "note",
 "content": "I’m baking halloween cookies!",
 },
 {
 "kind": "plus#activity",
 “id”: “456”,
 "title": "Cookies",
 "object": {
 "objectType": "note",
 "content": "Cookies and milk for dinner. Don’t judge me.",
 },
 ]
}

You can search for people by using the people.search method:

GET https://www.googleapis.com/plus/v1/people?query=vic%20gundotra&key=[yourAPIKey]

This searches across public profile information including fields such as name, bio, location, tag line, and description.

The rest of the conversation

Our first API release let you retrieve public posts. We’ve now added ways for you to see how people are publicly engaging with those posts -- you can find out who reshared a post or who +1’d a post, and you can read the comments on a post.

The new method people.listByActivity supports retrieving resharers and +1’ers by sending the following HTTP requests:

GET https://www.googleapis.com/plus/v1/activities/{activityId}/people/resharers?key=[yourAPIKey]
GET https://www.googleapis.com/plus/v1/activities/{activityId}/people/plusoners?key=[yourAPIKey]

And comments can be retrieved by the new comments.list and comments.get methods:

GET https://www.googleapis.com/plus/v1/activities/{activityId}/comments?key=[yourAPIKey]
GET https://www.googleapis.com/plus/v1/comment/{commentId}?key=[yourAPIKey]

Tell us what you think

As an API developer, I love seeing what people build on top of the APIs I’ve worked on. We have been reading your posts on the Discussion Board and issue tracker and I am excited to see more of your creative ideas. We will continue incorporating your feedback into our design discussions, so please keep it coming.

Follow the conversation on Google+.

Jordanna Chord is a Software Engineer on the Google+ API Team


Posted by Scott Knaster, Editor

By Jeremie Lenfant-Engelmann, Google Web Fonts Engineer

We’ve received lots of requests from developers for a dynamic feed of the most recent web fonts offered via Google Web Fonts. Such a feed would ensure that you can incorporate Google Web Fonts into applications and menus dynamically, without the need to hardcode any URLs. The benefits of this approach are clear. As Google Web Fonts continues to add fonts, these fonts can become immediately available within your applications and sites.

To address this need, we’ve built the Google Web Fonts Developer API, which provides a list of fonts offered via Google Web Fonts. Results can be sorted by alpha, date added, popularity, number of styles available, and trending (which is a measure of fonts growing rapidly in usage). Check out the documentation to get started.

Some developers have helped us test this new API over the last few months, and the results are already public. Take a look at TypeDNA’s photoshop plugin as well as Faviconist, an app that makes generating favicons as simple as can be, and Google Web Fonts Families, a list of Google Web Fonts that have more than one style.

We look forward to seeing what you come up with!

Jeremie Lenfant-Engelmann is a Software Engineer on the Google Web Fonts team.

Posted by Scott Knaster, Editor

By Richard Dunn, Technical Lead, Google+ platform for Hangouts

Cross-posted from the Google+ Platform Blog

In the three months since we launched face-to-face-to-face communication in Google+ Hangouts, I’ve been impressed by the many ways people use them. We’ve seen Hangouts for game shows, fantasy football drafts, guitar lessons and even hangouts for writers to break their solitary confinement. That’s just the beginning. Real-time applications are more engaging, fun, and interactive, but were hard for developers to deliver. Until now.

Today we’re launching the Developer Preview of the Hangouts API, another small piece of the Google+ platform. It enables you to add your own experiences to Hangouts and instantly build real-time applications, just like our first application, the built-in YouTube player.

The integration model is simple -- you build a web app, register it with us, and specify who on your team can load it into their Hangout. Your app behaves like a normal web app, plus it can take part in the real-time conversation with new APIs like synchronization. Now you can create a "shared state" among all instances of your app so that all of your users can be instantly notified of changes made by anyone else. (This is how the YouTube player keeps videos in sync.) And we’ve added our first few multimedia APIs so you can, for example, mute the audio and video feeds of Hangout participants.

When you’re ready to start hacking, we’re ready for you -- read the documentation, sign up, and start coding. We’re anxious to get your feedback, since this is a very early version of the API. We’ll be making improvements and moving towards full production based on what we learn together. And we’ll be releasing new updates on a regular basis, so stay tuned!

Follow the conversation on Google+.

Richard Dunn is Technical Lead, Google+ platform for Hangouts


Posted by Scott Knaster, Editor

By Yaniv Inbar, Google APIs Client Team

During Google I/O 2011, we announced a major milestone by releasing the Beta version of the open source Google APIs Client Library for Java. This release included service-specific libraries and samples for Google APIs, built on our new client library generation infrastructure. Since that version 1.4 launch, we’ve been comfortable enough with the stability and features of the library that we want you to start building real production Java 5, Android, and Google App Engine applications and send us your feedback.

Today we are announcing a new milestone for the Java client library. With the version 1.5 release, we’re making available the open source Google OAuth Client Library for Java in Beta, with support for both OAuth 1.0a and OAuth 2.0. OAuth is an open standard for allowing a client application to securely gain access to a user’s private data stored on Google without ever asking for their password. Most Google APIs support OAuth 2.0, and we want to encourage adoption of OAuth 2.0 more widely on the web. That’s why we built this library to work with any API on the web -- not just Google APIs -- that comply with the OAuth specifications. Our current implementation of OAuth 2.0 is based on draft 10, but we will update it soon to the final draft, once it becomes an official standard. We encourage you to try it and send us your feedback.

Here is an example of how easy it is to use the OAuth 2.0 library to make a request using the library for the Google+ API (check out more samples):

// Set up the HTTP transport and JSON factory
HttpTransport httpTransport = new NetHttpTransport();
JsonFactory jsonFactory = new JacksonFactory();
// Set up OAuth 2.0 access of protected resources 
// using the refresh and access tokens, automatically 
// refreshing the access token when it expires
GoogleAccessProtectedResource requestInitializer = 
 new GoogleAccessProtectedResource(accessToken, httpTransport, 
 jsonFactory, clientId, clientSecret, refreshToken);
// Set up the main Google+ class
Plus plus = new Plus(httpTransport, requestInitializer, jsonFactory);
// Make a request to access your profile and display it to console
Person profile = plus.people().get("me").execute();
System.out.println("ID: " + profile.getId());
System.out.println("Name: " + profile.getDisplayName());
System.out.println("Image URL: " + profile.getImage().getUrl());
System.out.println("Profile URL: " + profile.getUrl());

Finally, we are making available a Beta version of the open source Google HTTP Client Library for Java. This is the common HTTP client library that the above two libraries are built on, and is built to work with any API on the web. It features a pluggable HTTP transport abstraction that allows it to work seamlessly on any of the supported Java platforms, support for efficient JSON and XML data models for parsing and serialization, and a pluggable JSON and XML parser so you can use whatever works best for you. Please try it and send us your feedback.

We are looking forward to finding out what you can build using these libraries on Google APIs. Please let us know how we can make the libraries easier to use and better suited for your needs.

As we announced at Google I/O 2010, we've been developing APIs that can provide descriptions of themselves via metadata. This new technique makes it easier to create and maintain client libraries that support more languages, work with more APIs, and are easier to use than ever before. This post announces one of several recent major milestones for our client libraries.


Yaniv Inbar is a Senior Software Engineer and Technical Lead of the Google APIs Client Libraries & Tools team. He is the lead developer of the open source Google APIs Client Library for Java. Yaniv has worked at Google for 5 years, and has a total of 12 years industry experience as a software engineer.

Posted by Scott Knaster, Editor

By Jacob Moshenko and Gustavo Moura, Software Engineers

In January of this year we launched BigQuery integration with Google Apps Script. What we didn’t mention was that we were building this on top of our Google APIs Discovery Service. Thanks to the ease and flexibility of writing clients based on this API, today we’re announcing integration with three more APIs, and revamping our BigQuery support.

As of now, we have also integrated the Tasks API, Prediction API, and URL Shortener API in addition to the BigQuery API. You can now include these APIs in your scripts, apps, and sites pages. As with other Apps Script services, we handle all of the server communications as well as authorization, which makes this a great way to build mashups and workflows using our APIs.

To get started, simply enable the APIs you’re interested in from the "Use Google API services" menu in the script editor.


Using this feature will prompt you to save your script. Once you have done so, the Google APIs Services dialog will appear and you can choose which APIs to use, which versions to use, and what name to use when referencing them from your scripts.


After you complete this step, the API methods will be automatically populated as you type using the standard Apps Script autocomplete mechanism. For detailed information about each API, visit our reference documentation. We have also created a tutorial with a simple, fun application to help you get started using scripts.

As we iron out this new technology and listen to your feedback we plan to aggressively integrate even more APIs. If you have any questions or experience any problems let us know on our support forum.

Jacob Moshenko is a Software Engineer working on the Google APIs developer experience. He believes that Google APIs should be easy to use, especially from Google platforms.

Gustavo Moura has been a Software Engineer at Google since 2007. He has been part of the Google Docs team since 2009. Prior to that, he worked on AdWords.

Posted by Scott Knaster, Editor