G Suite Developers Blog: Google Data Protocol

Saying Goodbye to the GData Admin Settings API

August 16, 2016

Posted by Shashank Gupta, Product Manager, Google Apps for Work and Wesley Chun, Developer Advocate, Google Appslauncheddeprecated and shut down in April 2015GData Admin Settings API

Admin Settings API

Endpoint

Post-Deprecation Replacement (if any)

General Settings

/defaultLanguage

Directory API: Customers

/organizationName

Directory API: Customers

/currentNumberOfUsers

no replacement / discontinued

/maximumNumberOfUsers

no replacement / discontinued

Account Settings

/accountInformation/supportPIN

no replacement / discontinued

/accountInformation/customerPIN

no replacement / discontinued

/accountInformation/adminSecondaryEmail

Directory API: Customers

/accountInformation/edition

no replacement / discontinued

/accountInformation/creationTime

Directory API: Customers

/accountInformation/countryCode

Directory API: Customers

Appearance Settings

All endpoints

no replacement / discontinued

Verification Settings

All endpoints

no replacement / discontinued

Single Sign-on (SSO) Settings

All endpoints

replacement API coming before Aug 2017

Gateway and Routing Settings

All endpoints

no replacement / discontinued

GData Admin Settings APIuntil October 31, 2018,October 31, 2018

How we built a Social Network for Productivity on Top of Google Docs, Calendar, Contacts and Reader

May 2, 2012

Editor’s note: This is a guest post by Martin Böhringer, Co-Founder and CEO of Hojoki.
-- Steve Bazyl

Honestly, we love Google’s productivity tools. Back in 2010, when I was a computer science researcher at university, I was a heavy user of Google Docs, Google Calendar, Google Contacts and Google Reader. So it was the most natural thing to put these tools to the front for integrations into our startup, Hojoki.

Hojoki integrate productivity cloud apps into one newsfeed and enables sharing and discussions on top of the feed. We’ve integrated 17 apps now and counting, so it’s safe to say that we’re API addicts. Now it's Time to share with you what we learned about the Google Apps APIs!

The goal: a newsfeedOur initial reason for building Hojoki was because of the fragmentation we experience in all of our cloud apps. And all those emails. Still, there was this feeling of “I don’t know what’s going on” in our distributed teamwork. So we decided to build something like a Google+ where streams get automatically filled by activities in the apps you use.This leads to a comprehensive stream of everything that’s going on in your team combined with comments and microblogging. You can organize your stream into workspaces, which are basically places for discussions and collaboration with your team.

Information needsTo build this, we first need some kind of information on recent events. As we wanted to be able to aggregate similar activities and to provide a search, as well as splitting up the stream in workspaces, we also had to be able to sort events as unique objects like files, calendar entries and contacts.Further, it’s crucial to not only know what has changed, but who did it. So providing unique identities is important for building federated feeds. Google APIsGoogle’s APIs share some basic architecture and structure, described in their Google Data Protocol. Based on that, application-specific APIs provide access to the application’s data. What we use is the following:

Google Docs: Google Documents List API version 3.0

Google Calendar: Google Calendar API v2
Note: there is a new API v3 for Google Calendar

Google Contacts: Google Contacts API v2

The basic call for Google Contacts for example looks like this: https://www.google.com/m8/feeds/contacts/default/fullThis responds with a complete list of your contacts. Once we have this list all we have to do is to ask for the delta to our existing knowledge. For such use cases, Google’s APIs support query parameters as well as sorting parameters. So we can set “orderby” to “lastmodified” as well as “updated-min” to the timestamp of our last call. This way we are able to keep the traffic low and get quick results by only asking for things we might have missed.If you want to develop using those APIs you should definitely have a look at the SDKs for them. We used the Google Docs SDK for an early prototype and loved it. Today, Hojoki uses its own generic connection handler for all our integrated systems so we don’t leverage the SDKs anymore. Real world problemsIf you’re into API development, you’ve probably already realized that our information needs don’t fit into many of the APIs out there. Most of the APIs are object centric. They can tell you what objects are included in a certain folder, but they can’t tell you which object in this folder has been changed recently. They just aren’t built with newsfeeds in mind.Google Apps APIs support most of our information needs. Complete support of OAuth and very responsive APIs definitely make our lives easier.However, the APIs are not built with Hojoki-like newsfeeds in mind. For example, ETags may change even if nothing happened to an object because of asynchronous processing on Google’s side (see Google’s comment on this). For us this means that, once we detect an altered ETag, in some cases we still have to check based on our existing data if there really have been relevant activities. Furthermore, we often have trouble with missing actors in our activities. For example, up to now we know when somebody changed a calendar event, but there is no way to find out who this was.Another issue is the classification of updates. Google’s APIs tell us that something changed with an object. But to build a nice newsfeed you also want to know what exactly has been changed. So you’re looking for a verb like created, updated, shared, commented, moved or deleted. While Hojoki calls itself an aggregator for activities, technically we’re primarily an activity detector. Final solutionYou can think of Hojoki as a multi-layer platform. First of all, we try to get a complete overview on your meta-data of the connected app. In Google Docs, this means files and collections, and we retrieve URI and name as well as some additional information (not the content itself). This information fills a graph-based data storage (we use RDF, read more about it here).At the moment, we subscribe to events in the integrated apps. If detected, they create a changeset for the existing data graph. This changeset is an activity for our newsfeed and related to the object representation. This allows us to provide a very flexible aggregation and filtering on the client side. See the following screenshot. You can filter the stream for a certain collection (“Analytics”) or only for the file history or for the Hojoki workspace where this file is added (“Hojoki Marketing”).

What’s really important in terms of such heavy API processing is to use asynchronous calls. We use the great Open Source project async-http-client for this task. A wishlistWhen I wrote that “we subscribe to events” this is a very nice euphemism for “we’re polling every 30s to see if something changed”. This is not really optimal and we’d love to change it. If Google Apps APIs would support a feed of user events modelled in a common standard like ActivityStrea.ms, combined with reliable ETags and maybe even a push API (e.g. Webhooks) this would also make life easier for lots of developers syncing their local files with Google and help to reduce traffic on both sides.

Martin Böhringer

Martin is Co-Founder and CEO of Hojoki. Hojoki integrates Google Docs, Calendar, Contacts and Reader next to other apps like Dropbox and Evernote into one newsfeed, showing changes by co-workers in one central place. Martin holds a PhD in information systems and likes to perform on stage at Tech Events.

Google Data Authentication Choices

August 30, 2010

Editor's Note:Jeff Morgan is a Senior Technical Consultant at Appirio, a cloud solution provider which creates products and delivers services . He’s worked with many Google Data APIs, so we’re excited to publish his insights on the various authentication choices.Getting Started with Account AuthorizationAuthentication in Google Data Protocol

Does your application need end user permission to access their Google data?

When developing web applications, developers are sometimes faced with deciding between AuthSub or OAuth. However, the first question should be, "Who will be granting permission to the user's Google data?" If the end users are Google Apps users then most likely it will be an administrator granting access. Frequently developers ask the same question in another way, "Should I use 3-legged or 2-legged authentication?" Ideally, from a Google Apps user experience perspective, it is better to use 2-legged OAuth. This way the application is granted access to a user's Google Apps data at the administrator level. The end user can start to use the application and the trust has already been established by an administrator. If you are developing a Marketplace application then it is very likely you will not need to engage in the 3-legged authentication dance.
However, if you are writing an application that is wide open to anyone with a Google account, let the 3-legged dance begin. Both AuthSub and OAuth for Web Applications are designed for this purpose. However, the behavior and look and feel for each is slightly different. Both ultimately allow the user to grant your application access to their data, but knowing the differences helps you make the best choice. Here is an article that covers the topic and should help you choose. It has color coded highlights that compare the two.

Some general rules follow when choosing an authentication method:

End User	Authentication
Google User (regular)	AuthSub or 3-Legged OAuth (3LO)
Googe Apps User (hosted)	2-Legged OAuth (2LO)
No end user	2LO or ClientLogin

Gadgets

Again there are different options for choosing Google Data authentication from a Gadget container. The first option to consider is OAuth Proxy for Gadgets. OAuth proxy is a 3-legged dance asking the end user for permission to access their data. Once access has been granted then the gadget developer can use the gadgets.io.makeRequest()method to make the Google Data API calls. Most likely you will want the JSON response from the feed so remember to add the ?alt=json URL parameter. For more information and code examples on OAuth Proxy see Writing OAuth Gadgets.

For Marketplace Gadgets another authentication option is available and uses OpenID. This option is used to authenticate the user and determine identity only and it does not provide authorization for API access. After the user is authenticated, server-to-server calls are used to make the requests, authorized via 2-legged OAuth and specifying the xoauth_requestor_id based on the authenticated user from OpenID. For more information on this approach see the Marketplace Best Practices page.

Secure Storage of Credentials

Adding layers of security is a common approach to to making data more secure. Google does provide various layers by providing different authentication and authorization methods. Registering web applications, supporting digital certificates, support for industry standards, (SAML, OAuth, OpenID) all help in providing security. However, one of the most common mistakes we can make is not taking care to protect important credentials. When working with Google Data ClientLogin and 2-legged OAuth, these credentials can be keys to the kingdom (e.g. administrator credentials or domain OAuth consumer secret) and therefore should be protected at all costs. Access to these credentials can potentially open the entire Google Apps domain data for the authorized services. This could have tremendous impact especially if you are maintaining 2-legged OAuth credentials for domains that have granted your application access, e.g. a Marketplace application. Therefore it is risky practice to embed them in source code or even a configuration file. Consider using an approach that allows you to enter credentials at runtime and store in memory or use your favorite method for secure storage of these important credentials.

Google Apps Marketplace

With the March announcement of the Google Apps Marketplace, the decision making process may have become a little easier. OpenID+OAuth and 2-Legged OAuth are the schemes that are supported and likely will be used if your Marketplace application needs access to Google Apps data; which is very likely. You’ll notice that the Marketplace has embraced the open standards of OpenID and OAuth. While AuthSub and ClientLogin are proprietary to Google, they will likely not be useful in your Marketplace application.

ClientLogin

If your application needs to create or make modifications to user accounts (using the Provisioning API) then your only current option is ClientLogin. But a common oversight is to not reuse the access token. Without proper reuse of this token, eventually your application will force the account into a CAPTCHA state which can easily be avoided if the access token is used for subsequent ClientLogin authentication requests. It is best to keep this token cached in memory and renew the token in some configured frequency/timeout.

Summary

This post covered some important considerations for selecting a Google Data authentication method for your application. If you are new to Google Data authentications and want to have a better overall understanding then start with the Getting Started with Account Authorization guide. No matter which approach you choose make sure that accessing users data is done is a secure user friendly way.

References

Google Data authentication is a vast topic. For your convenience here are a list of resources.

Google Data Authentication - Start Here
Getting Started with Account Authorization
Authentication in the Google Data Protocol
OAuth
OAuth in the Google Data Protocol Client Libraries
OAuth for Web Applications
OAuth for Installed Applications
OAuth API Reference
Using OAuth with the Google Data APIs
Google Data API Tips - OAuth
OAuth Playground
OAuth-enabled http test client: oacurl
Gadgets
Authentication for Gadgets
Writing OAuth Gadgets
Fetching Remote Content
Creating a Google Data Gadget
JavaScript client library API reference
Using JSON with Google Data APIs
OAuth Enabled Gadgets on OpenSocial enabled Social Networks
Registration
Registration for Web-Based Applications
OpenID
Federated Login Service for Google Apps
OpenID+OAuth
Sharing and previewing Google Docs in Socialwok: Google Data APIs
Step2 Code Project
OpenID OAuth Extension
ClientLogin
ClientLogin in the Google Data Protocol Client Libraries
ClientLogin for Installed Applications
Google Data API Blog - ClientLogin
AuthSub
AuthSub Authentication for Web Applications
Using AuthSub in the Google Data Protocol JavaScript Client Library
Google Data API Tips - AuthSub

Google I/O
OpenID-based single sign on and OAuth data access for Google Apps

By Jeff Morgan, Senior Technical Consultant at Appirio

Want to weigh in on this topic? Discuss on Buzz

Expensify Accelerates Sign ups with the Provisioning API

August 27, 2010

Editor's Note:This post was written by Zhenya Grinshteyn and Tom Jacobs of Expensify. We invited Expensify to share their experience with the Google Apps Marketplace.
Expensify does expense reports that don't suck by importing expenses and receipts from your credit cards and mobile phones, submitting expense reports through email, and reimbursing online with QuickBooks and direct deposit.

The Foundation: Single Sign-On

We were really excited when Google approached us to be a launch partner for their new Google Apps Marketplace because tons of our customers use Google Apps -- including us! We have long wanted to put an 'Expenses' link up there next to Mail and Documents, and now we had our chance.

To do that, we installed the JanRain PHP OpenID library with the Google Apps Discovery extension. We’d already implemented Gmail OpenID and ironed out the kinks related to having multiple logins to a single account, so implementing this was a very straightforward process.

Lessons Learned

We quickly learned that while single sign-on is awesome, there was a high drop-off rate among admins installing Expensify into their domain. Digging deeper we determined it was due to the setup process being split: part of the setup was done from within Google Apps, but the final part had to be completed by signing in to our site. Not only that, a major part of the setup process was laboriously entering their employee’s emails. We decided to address each in turn by creating a setup wizard and importing the domain’s email list. We approached this change in two major ways:
First, when the Google Apps admin installs the Expensify application, we created a custom configuration step that creates what we call an 'expense policy'. This governs everything from who is part of the company, who can approve expenses, and ultimately who exports to QuickBooks to keep the general ledger in check. Previously this step had to be done after the application was already installed, usually when the admin first signed in. By making this step part of the install process, the entire setup felt much more intuitive and resulted in a higher completion rate.

Second, we used the Zend framework to connect to the Google Apps Provisioning API to fill the new expense policy with a list of all existing employees. This saved a ton of typing and resulted in a vast reduction in the time it took to deploy Expensify to the full company. With everything else in place, the code we used to do this looked something like this:

$oauthOptions = array(
     'requestScheme' => Zend_Oauth::REQUEST_SCHEME_HEADER,
     'version' => '1.0',
     'signatureMethod' => 'HMAC-SHA1',
     'consumerKey' => $CONSUMER_KEY,
     'consumerSecret' => $CONSUMER_SECRET
 );
 $consumer = new Zend_Oauth_Consumer($oauthOptions);
 $token = new Zend_Oauth_Token_Access();
 $httpClient = $token->getHttpClient($oauthOptions);
 $service = new Zend_Gdata_Gapps($httpClient, $domain );
 $users = $service->retrieveAllUsers();

All of the users’ names and emails are presented in a table of employees that the person installing the app can use to set roles and quickly build an approval tree for all expenses.

Once the setup is completed, we automatically create accounts for all of the selected employees and send out a brief email with tips to get started.

Results: 3.5x more users sign up

Overall it was a fast and painless process, has increased the flow of high-quality leads, and has accelerated their rate of converting into real users. Domain admins now sign up 3.5x more users right away than they have been using the previous two-part setup! Feel free to install our app to see how the setup process works, and respond to this post with questions about your implementation -- we'll try to help out as best we can. And of course if you're still doing your expense reports the old sucky way, please come visit our website (Expensify.com) and we'd be happy to help ease your pain. Thanks for reading, let me know if there's anything I can help clarify!

Posted by Zhenya Grinshteyn, Expensify

Want to weigh in on this topic? Discuss on Buzz

Reminder: Google Apps Hackathon on Tuesday, August 24th

August 16, 2010

siteGoogle AppsGoogle Apps MarketplaceTentative Agenda:

Marketplace APIs

OpenID & OAuth

Gmail contextual gadgets

Administrative APIs

Docs APIs

Calendar APIs

Contacts APIs

When:Where:register herePosted by Steven Bazyl, Google Apps Marketplace TeamWant to weigh in on this topic? Discuss on Buzz

Sharing and previewing Google Docs in Socialwok: Google Data APIs

April 9, 2010

Editor's note:Navin Kumar is CTO and co-founder of Socialwok, a feed-based group collaboration application for enterprises that integrates with Google Apps. With Socialwok, Google Apps users can create their own private social network to share Google Docs, Calendars and Spreadsheets with their coworkers. Navin and his team built Socialwok on Google App Engine for Java, Google Web Toolkit and Google GData APIs. Socialwok will be at the Google IO sandbox May 19 - 20, 2010.http://www.socialwok.com/tourSharing and Previewing Google Docs in feedsintegrated with the workflowright inside Gmail

Uploading a Microsoft Powerpoint file for sharing using Google Docs

Successful posting of the Google Presentation shared in a feed

Previewing the Google Presentation from the Socialwok web using the Google Data APIUsing Google Docs viewer to preview Google Docs, PDF, PPT, XLS in Socialwok Desktop and Mobile Webrecent release

Preview of a shared pdf document from Socialwok's desktop web application using the Google Docs ViewerGoogle Docs supported formats

Preview of a shared pdf document using Google Docs viewer from Socialwok's HTML 5 mobile web pageSharing Google Docs using the Google Data APIsEntity currentUser = (Entity) httpRequest.getSession()
.getAttribute("userObject");hereQuery query = new Query("GoogleAccount", currentUser.getKey());
Entity googleAccount = dataService.prepare(query).asSingleEntity();
GoogleOAuthParameters oauthParameters = new GoogleOAuthParameters();
oauthParameters.setOAuthConsumerKey(
oauthProps.getProperty("google.consumerKey"));
oauthParameters.setOAuthConsumerSecret(
oauthProps.getProperty("google.consumerSecret"));
oauthParameters.setOAuthToken(
(String) googleAccount.getProperty("oauthToken"));
oauthParameters.setOAuthTokenSecret(
(String) googleAccount.getProperty("oauthSecret"));MediaStreamSourceDocsService service = new DocsService("Socialwok-v1");
service.setOAuthCredentials(oauthParameters,signer);

MediaStreamSource streamSource = new MediaStreamSource(fileInputStream,
contentType);
streamSource.setName(filename);
DocumentListEntry inserted = service.insert( new URL(
"http://docs.google.com/feeds/default/private/full/?convert="+
doConvert), DocumentListEntry.class, streamSource);convertPreviewing Google Docs using the Google Data APIshttps://docs.google.com/a/socialwok.com/View?docid=0Adnk...dkZmNoOTIyNQhttps://docs.google.com/a/socialwok.com/Doc?docid=0Adnk...dkZmNoOTIyNQ

Get the Google Docs entry from the datastore.

Entity fileAttachment = datastoreService.get(attachmentKey);
String entryId = fileAttachment.getProperty("fileId");

Get the Google Docs entry from the Google Docs GData Service.

URL entryUrl = new URL(entryId);
DocumentListEntry docEntry = service.getEntry(entryUrl,
    DocumentListEntry.class);

Get the document link from the Google Docs Entry

String docLink = docEntry.getDocumentLink().getHref();

Convert the link to the viewer.

if (docEntry instanceof DocumentEntry) {
    docLink = docLink.replace("/Doc","/View");
}

Document Type

Action

URL

Document

Edit

https://docs.google.com/a/<domain>/Doc?docid=...

Dcument

View

https://docs.google.com/a/<domain>/View?docid=...

Presentation

Edit

https://docs.google.com/a/<domain>/present/edit?id=...

Presentation

View

https://docs.google.com/a/<domain>/present/view?id=...

Spreadsheet

Edit

https://spreadsheets.google.com/a/<domain>/ccc?key=...

Spreadsheet

View

https://spreadsheets.google.com/a/<domain>/lv?key=...

Previewing PDF, PPT, and XLS files using the Google Document Viewerhttp://docs.google.com/viewerTechnical Documentation - Instructions for building your own URLs
All viewer URLs should use the path http://docs.google.com/viewer . This path accepts two parameters:
url : The URL of the document to view. This should be URL-encoded.
embedded : If set to true , the viewer will use an embedded mode interface.

For example, if you wanted to view the PDF at
http://labs.google.com/papers/bigtable-osdi06.pdf,
you would use the URL:

http://docs.google.com/viewer?url=https%3A%2F%2F2.gy-118.workers.dev/%3A443%2Fhttp%2Flabs.google.com%2Fpapers%2Fbigtable-osdi06.pdf

embeddedhttp://docs.google.com/viewer?url=https%3A%2F%2F2.gy-118.workers.dev/%3A443%2Fhttp%2Flabs.google.com%2Fpapers%2Fbigtable-osdi06.pdf&embedded=true<IFRAME><iframe src="">http://docs.google.com/viewer?url=https%3A%2F%2F2.gy-118.workers.dev/%3A443%2Fhttp%2Flabs.google.com%2Fpapers%2Fbigtable-osdi06.pdf&embedded=true" style="width:600px; height:500px;" frameborder="0"></iframe>Frameimport com.google.gwt.user.client.ui.Frame;
...
Frame viewerFrame = new Frame();
viewerFrame.setUrl("http://docs.google.com/viewer?url=https%3A%2F%2F2.gy-118.workers.dev/%3A443%2Fhttp%2Flabs.google.com%2Fpapers%2Fbigtable-osdi06.pdf&embedded=true");
viewerFrame.setHeight("500px");
viewerFrame.setWidth("600px");
containerWidget.add(viewerFrame);Google Docs blogExtending Socialwok using our APIs. Meet Socialwok at Google IOhttp://blog.socialwok.cominfo@socialwok.comDeveloper Sandboxinfo@socialwok.comBy Navin Kumar, Socialwok

Making Google Calendar Applications Faster: Partial Response and Update

March 25, 2010

Google Calendar Data APIGET http://www.google.com/calendar/feeds/example@google.com/private/full?fields=entry(title,gd:when)<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:gd="http://schemas.google.com/g/2005">
<entry>
<title type="text">Example meeting</title>
<gd:when endTime="2010-03-25T09:00:00.000-07:00" startTime="2010-03-25T08:00:00.000-07:00">
<gd:reminder method="alert" minutes="10"/>
<gd:reminder method="sms" minutes="10"/>
</gd:when>
</entry>
... more entries ...
</feed>PATCHPATCHgd:fieldPATCH http://www.google.com/calendar/feeds/default/private/full/eventID HTTP/1.1
Content-Type: application/xml
Host: www.google.com
GData-Version: 2
If-Match "FE8LQQJJeSp7IWA6WhVa"

<?xml version="1.0" encoding="UTF-8"?>
<entry>
<title type="text">Example meeting update</title>
<gd:when endTime="2010-03-27T10:00:00.000-07:00" startTime="2010-03-27T09:00:00.000-07:00">
<gd:reminder method="alert" minutes="10"/>
<gd:reminder method="sms" minutes="10"/>
</gd:when>
</entry>Developer’s Guidepost on the Google Code BlogPosted by Peng Ying, Google Calendar API Team

Resumable Upload for the Google Data APIs

March 22, 2010

backing up local filesDocuments List APIGoogle Data APIsResumableHttpRequestsProposalPOST /feeds/upload/create-session/default/private/full?convert=false HTTP/1.1
Host: docs.google.com
GData-Version: 3.0
Authorization: <your authorization header here>
Content-Length: 292
Content-Type: application/atom+xml
X-Upload-Content-Type: application/msword
X-Upload-Content-Length: 7654321

<?xml version='1.0' encoding='UTF-8'?>
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:docs="http://schemas.google.com/docs/2007">
<category scheme="http://schemas.google.com/g/2005#kind"
term="http://schemas.google.com/docs/2007#document"/>
<title>MyTitle</title>
<docs:writersCanInvite value="false"/>
</entry>Content-RangePUT <unique_upload_uri> HTTP/1.1
Host: docs.google.com
Content-Length: 100000
Content-Type: application/pdf
Content-Range: bytes 0-99999/1234567

<bytes 0-99999>documentationclient library samplesPosted by Eric Bidelman, Google Apps API Team