It’s been almost four years since the Calendar API has supported the JSON format. However, our existing JSON format isn’t perfect. It is very much an automatic translation from our Atom format and as a result it is very wordy and lacks the elegance that a native JSON dialect would offer. It also supports only read operations.
It’s been almost four years since the Calendar API has supported the JSON format. However, our existing JSON format isn’t perfect. It is very much an automatic translation from our Atom format and as a result it is very wordy and lacks the elegance that a native JSON dialect would offer. It also supports only read operations.

We have made our new JSON implementation cleaner, simpler and closer to what you would expect from JSON. For example, the long XML namespace prefixes are no more, and we've removed many pieces of metadata specific to Atom documents that come across as noise in JSON, making it easier to parse.

We’re calling this new format JSON-C. One of the major advantages of the JSON-C format, besides being read-write and more readable than the former JSON implementation, is that it is more compact than the Atom based format. Below is an example:

Creating an event using JSON-C

POST /calendar/feeds/default/private/full HTTP/1.1
Host: www.google.com
Authorization: ...
Content-Type: application/json
GData-Version: 2.0
Content-Length: 233

{
"data": {
"title": "Tennis with Beth",
"details": "Meet for a quick lesson.",
"transparency": "opaque",
"status": "confirmed",
"location": "Rolling Lawn Courts",
"when": [
{
"start": "2010-04-17T15:00:00.000Z",
"end": "2010-04-17T17:00:00.000Z"
}
]
}
}

Creating an event using Atom

POST /calendar/feeds/default/private/full HTTP/1.1
Host: www.google.com
Authorization: ...
Content-Type: application/atom+xml
GData-Version: 2.0
Content-Length: 571

<entry xmlns='http://www.w3.org/2005/Atom' xmlns:gd='http://schemas.google.com/g/2005'>
<category scheme='http://schemas.google.com/g/2005#kind'
term='http://schemas.google.com/g/2005#event'/>
<title type='text'>Tennis with Beth</title>
<content type='text'>Meet for a quick lesson.</content>
<gd:transparency value='http://schemas.google.com/g/2005#event.opaque'/>
<gd:eventStatus value='http://schemas.google.com/g/2005#event.confirmed'/>
<gd:where valueString='Rolling Lawn Courts'/>
<gd:when startTime='2006-04-17T15:00:00.000Z' endTime='2006-04-17T17:00:00.000Z'/>
</entry>
In the example above the body of the request is 59% smaller in JSON-C than in Atom. If you use gzip compression, the saving is still 37% of the size of the Atom body. This could make a big difference in mobile or other bandwidth-constrained environments.

To retrieve events or other data in the JSON-C format, you have to specify the ‘alt’ URL parameter with the value ‘jsonc’ as shown below:

Requesting an event in JSON-C

GET /calendar/feeds/default/private/full/1234567890?alt=jsonc HTTP/1.1
Host: www.google.com
Authorization: ...
GData-Version: 2.0

Response

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
...
{
"apiVersion": "2.3",
"data": {
"title": "Tennis with Beth",
"details": "Meet for a quick lesson.",
"location": "Rolling Lawn Courts",
...
}
}
For the request above, the body of the response is 53% smaller in JSON-C than in Atom - 30% smaller when using gzip compression.

To learn more about our new JSON-C format please read our updated Developer’s Guide. Have fun!

Want to weigh in on this topic? Discuss on Buzz

This post was originally published on the Google Enterprise Blog. We decided to re-post it here as we think it'll be interesting to readers of the Google Apps Developer Blog. ...
Editor's Note: This post was originally published on the Google Enterprise Blog. We decided to re-post it here as we think it'll be interesting to readers of the Google Apps Developer Blog.

Google Apps is designed to provide a secure and reliable platform for your data. Until today, Google Apps administrators had to sign requests for calls to Google Apps APIs using their username and password (this is called ClientLogin Authorization).

Yet sharing passwords across sites can pose security risks. Furthering our commitment to make the cloud more secure for our users, today we are pleased to announce support for OAuth authorization on Google Apps APIs.

There are several advantages to using OAuth instead of the username/password model:
  • OAuth is more secure: OAuth tokens can be scoped and set to expire by a certain date, making them more secure than using the ClientLogin mechanism.
  • OAuth is customizable: Using OAuth, you can create tokens that scripts may only use to access data of a particular scope when calling Google Apps APIs. For instance, a token set to call the Email Migration API would not be able to use your login credentials to access the Google Apps Provisioning API.
  • OAuth is an open standard: OAuth is an open source standard, making it a familiar choice for developers to work with.
The Google Apps APIs that support the OAuth signing mechanism are:

1. Provisioning API
2. Email Migration API
3. Admin Settings API
4. Calendar Resource API
5. Email Settings API
6. Audit API

OAuth support for Google Apps APIs is another step towards making Google Apps the most secure, reliable cloud based computing environment for organizations. To learn more about OAuth support and other administrative capacities launched in Google Apps this quarter, join us for a live webinar on Wednesday, September 29th at 9am PT / 12pm EST / 5pm GMT.

Administrators for Google Apps Premier, Education, and Government Editions can use OAuth authorization for Google Apps APIs starting today.For more information about the OAuth standard, visit http://oauth.net.

Want to weigh in on this topic? Discuss on Buzz

One of the core requirements of preparing an application for launch on the Google Apps Marketplace is integrating with OpenID-based Single Sign-On. This enables Google Apps users to access your application without creating and maintaining additional credentials. This lowers the barrier to entry for your application and creates a seamless on-boarding flow.
One of the core requirements of preparing an application for launch on the Google Apps Marketplace is integrating with OpenID-based Single Sign-On. This enables Google Apps users to access your application without creating and maintaining additional credentials. This lowers the barrier to entry for your application and creates a seamless on-boarding flow.

In addition to making your app easier to use, OpenID can improve security for applications by reducing the number of places you need to enter a password. Of course, it’s also important to strengthen the security of the places you are entering your password, and yesterday’s launch of Two-step verification does just that.

Until yesterday, Google Apps customers using Google Apps’ built-in authentication mechanisms needed to provide a username and password (something they knew) to log in. Our launch of 2-factor authentication, which we’re calling Two-step verification, enables users of Premier, Education and Government Editions to additionally require having something in possession- a mobile phone- to log in.

So, if you’re a Marketplace developer and your customer asks you if your app supports 2-factor auth, you can answer an emphatic “yes” and send them over to the Marketplace to add your app to their domain.

Want to weigh in on this topic? Discuss on Buzz

Since launching the Apps Marketplace back in March, we’ve been heads down working on our Marketplace billing API, which is based on Google Checkout. The goal of the API is to make it easy for Marketplace vendors to sell their installable applications to Google Apps customers, using either a subscription model or one-time payment, and accommodating both free trial and freemium pricing plans. We are excited to get it in to developers’ hands.

Our current plan is to release it in Q4 for US sellers, and then expand to other seller countries in the following months. Please see our FAQ for more information on supported countries, and watch this blog or sign up to our email announcement list to be notified of changes.

Marketplace Payment Policy Updated

As a reminder, our Marketplace payment policy launched with a revenue sharing exemption period, which lasts until 3 months after the release of these billing APIs. Upon expiration, all installable apps sold through the Marketplace are required to integrate with these billing APIs and bill new customers acquired through the Marketplace exclusively through these APIs.

However since our seller country list is may be smaller than the list of countries where our vendors are located, we have updated our payment policy to extend the revenue sharing exemption period until 3 months after it is released in a country where you are located.

Put more concretely, if you are a Google Apps Marketplace vendor located in Australia or India or any other country not currently on our seller list, your revenue sharing exemption period remains in effect until 3 months after the billing API supports your country.

We encourage you to read the payment policy in full to make sure you understand it, and consult our FAQ for more information. Note that the availability of the revenue exemption, including the determination of where a developer is located for purposes of the exemption, is entirely at our discretion.

Since launching the Apps Marketplace back in March, we’ve been heads down working on our Marketplace billing API, which is based on Google Checkout. The goal of the API is to make it easy for Marketplace vendors to sell their installable applications to Google Apps customers, using either a subscription model or one-time payment, and accommodating both free trial and freemium pricing plans. We are excited to get it in to developers’ hands.

Our current plan is to release it in Q4 for US sellers, and then expand to other seller countries in the following months. Please see our FAQ for more information on supported countries, and watch this blog or sign up to our email announcement list to be notified of changes.

Marketplace Payment Policy Updated

As a reminder, our Marketplace payment policy launched with a revenue sharing exemption period, which lasts until 3 months after the release of these billing APIs. Upon expiration, all installable apps sold through the Marketplace are required to integrate with these billing APIs and bill new customers acquired through the Marketplace exclusively through these APIs.

However since our seller country list is may be smaller than the list of countries where our vendors are located, we have updated our payment policy to extend the revenue sharing exemption period until 3 months after it is released in a country where you are located.

Put more concretely, if you are a Google Apps Marketplace vendor located in Australia or India or any other country not currently on our seller list, your revenue sharing exemption period remains in effect until 3 months after the billing API supports your country.

We encourage you to read the payment policy in full to make sure you understand it, and consult our FAQ for more information. Note that the availability of the revenue exemption, including the determination of where a developer is located for purposes of the exemption, is entirely at our discretion.

Want to weigh in on this topic? Discuss on Buzz

: This post was written by Avi Muchnick, CEO of Aviary, and edited by Don Dodge of Google. We invited Aviary to share their experiences integrating their app with Google Apps.
Editor's Note: This post was written by Avi Muchnick, CEO of Aviary, and edited by Don Dodge of Google. We invited Aviary to share their experiences integrating their app with Google Apps.

Aviary is a multimedia editing suite that lets people edit and retouch images, create logos, markup screen shots and even edit audio. Aviary is available on the Google Apps Marketplace, and can be accessed right from the Google Apps navigation bar.

One of the feature Aviary built as part of this integration with Google Apps was letting users save their Aviary creations to their Google Docs account. Integrating Aviary's suite of editors and their associated files into Google Docs was a terrific challenge for the team. Google provided Aviary with a great initial set of APIs to let Google Apps users navigate to and launch Aviary from within their universal navigation.


Users could retrieve Google Docs files within the Aviary editors once they were launched (via the DocList API). However, Aviary found that although saving the files to Docs was easy, there was no way to associate an Aviary editor to a specific file type (i.e. jpg) and make it launch Aviary's editors directly from inside Google's interface.

Focusing on the User Experience

Aviary wanted a way to make the experience truly seamless for Google's users. Having separate areas to manage Aviary files and Google Docs was a less than ideal user experience. Add in the fact that many more third party apps will be launching in Google's marketplace and the end result would be an organizational nightmare for users trying to remember where all of their files were stored.

Keeping things in one universal interface was imperative, but there was no native API for that yet. So to protect the user experience in the interim, Aviary needed to come up with a novel work around. Fortunately, there was a simple and elegant way.

Because Google does allow creating new native Documents using the DocumentService.Insert method of the DocList API, Aviary was able to create "stub documents" with private references to the actual Aviary document inside of them. Each stub document contains a thumbnail of the final image and a private (but shareable) URL that launches the Aviary editor with the original editable Aviary ".egg" file inside of it (".egg" is our native file format - it seemed apropos for Aviary).


Another benefit of this approach is that it allows Aviary to work with Google Apps Standard accounts which ordinarily do not allow the uploading of arbitrary custom file types, (unlike the Google Apps Premier accounts which do).

Collaboration Management

Best of all, routing the file through Google Docs means that managing permissions on who can edit and see the document is as simple as managing permissions on any Google Document. Aviary didn't need to reinvent the wheel.




Presentation of Aviary files within Google Docs

Aviary is a suite of design applications that are mostly design oriented although they do have audio editing capabilities as well. This means that most files created in Aviary are visual in nature. Browsing through a list of file names when looking for a visual file can be inefficient - but just by sticking with some of Google's native functionality worked well. Google's Docs list has a little-known Grid view button, which displays Google Docs using a grid of thumbnails.



Grid view gives the user a visual thumbnail preview of the contents of their Google Docs - including the stub documents we made. Perfect for finding Aviary files!



Document Organization

To make things simpler to find and organize, all of the stub files are in an Aviary folder by default. To facilitate file and folder management, Aviary wrapped the Gdata classes provided by Google with an Aviary helper class that provided all of the functionality needed to create folders, upload and replace files. Within this class, Aviary used the DocumentService.Insert method of the DocList API to add an AtomEntry with a category of "folder" to create this base folder.



One additional thing Aviary did was to automatically create a Help File in a user's Google Docs list the very first time an Apps user clicks on the Aviary link in Google's universal navigation. This help file contains an overview of the different Aviary editors that are available and some tips on how to use them. Aviary used the same DocumentService.Insert method of the DocList API to create this help document that was used to create the stub documents. Aviary sends the user a one-time summary email with the contents of this help file to make sure they can find the answers they need in the future.



When put all together, we now have a workable application that integrates smoothly with Google apps, giving all Apps users complete access to Aviary's multimedia editing suite. The more developers build on Google's Apps platform, the more useful it is to users, and the more everyone's apps are used as a result.


Want to weigh in on this topic? Discuss on Buzz

This is the first in a series of posts looking at the varied integration options with Google Apps and the Google Apps Marketplace. With that in mind, what better place to start off than users’ first experiences with your application -- the initial setup and login process.
This is the first in a series of posts looking at the varied integration options with Google Apps and the Google Apps Marketplace. With that in mind, what better place to start off than users’ first experiences with your application -- the initial setup and login process.

The more work an application requires just to get started, the more opportunities there are for administrators and users to abandon the application and try something else or give way to complacency. Yet simply thrusting users into an app with no help to get started can be equally as frustrating. Finding the right balance can be tricky, but giving users the right choices at the right times can make all the difference in converting users into productive and happy customers.

Get critical information up front

One of the first opportunities to engage users is when they’re installing your application. With a simple additional <link> in your manifest, you can easily alter the installation flow and bring the administrator to your site while you have their attention. This is the perfect time to gather whatever information your application requires before basic functionality can be enabled, particularly if that information is best handled by an administrator or business owner.


Let’s take a look at how we would build this out with our SaasyVoice demonstration application we wrote for our talk at Google I/O. Here’s a quick mockup of what an administrator would see when they click through to setup the application.


There are a few important things to point out here.
  1. We want to keep administrators focused and guide them through the setup so they complete it the first time through, so it helps to set expectations up front.
  2. We’d like to make sure our existing customers can take advantage of the integration with Google Apps and make it clear how they should proceed (we’ll leave the details behind that link for another post!)
  3. We still need to ask for some information about the company, but we want to be careful not to ask for things we can otherwise discover for ourselves. To get information like the administrators name and email address, we simply authenticate them with OpenID prior to displaying the page and ask for the attributes we need.

Make provisioning users easy

During this step of the install, its helpful to guide the administrator through properly configuring the app for the end users. For some applications, this could be assigning the appropriate roles to managers and employees or, in the case of SaasyVoice, assigning the user a phone extension. To accomplish this, Marketplace Apps can take advantage of the provisioning API to discover user and groups for a domain and learn which users are privileged administrators.

Help admins spread the word

Administrators need to do more than just install the application on their domain. Notifying and providing users with the knowledge needed to use the application effectively can be a challenge. Using the same data from the provisioning API, we can help admins get their users up to speed by sending instructions to each user. Of course we want to be good email citizens too and not email users without the administrators consent.


It’s important to remember that this is all happening within the context of the Marketplace’s installation process, and it’s important to return the admin back to Google Apps to complete the process and enable the application for their domain. Give administrators too many choices or too much freedom and there’s a good chance they’ll fall out of that process and leave the application inaccessible to users.

Don’t forget the users!

We’ve covered things well from the administrators side of things, and we were able to help them set up the application quickly by taking advantage of the integration options and data available to us. The last piece to the puzzle is making sure users have an equally positive experience.

Applications that create accounts on demand can use many of the same techniques to minimize setup time for each user. We can also take advantage of a user’s first log in to display important messages and tips to help them get started.


While the examples here are just mock ups, many apps in the Marketplace have already adopted these and other techniques. Our integration guide on code.google.com has a few examples, or you can try out some apps for yourself in the marketplace. More importantly, developers have learned that investing the time and resources to craft a great first experience for their apps pays off.

Stay tuned for the next in this series on Google Apps integration best practices!

Want to weigh in on this topic? Discuss on Buzz

In the last 5 months, we've worked with over 150 companies who have launched apps in the Google Apps Marketplace. In our conversations with developers, marketing teams, and business execs, it's become clear we would all benefit from a wider conversation and debate -- beyond one-on-ones.

So we took the logical next step and created an email-based Google Apps Marketplace forum, and then embedded it in our documentation and program sites so it’s easier to find. Starting today, it's the best place we know of to engage folks in the Apps Marketplace community to discuss trends, pricing models, brainstorm features, or just gripe about stuff.

Join the forum and dive in!

But wait, there’s more

There’s a wider Google Apps solution provider community beyond Marketplace developers however. Google Apps resellers, integrators, and consultants are equally passionate about innovating with customers in the cloud. And here at Google, we’re growing an equally passionate team to work with you all, our extended community.

But our team has a problem: we have a lot of news and observations to share, large and small, but no good way to share them in a way that enables an easy conversation. You know, Twitter-style, but with the ability to actually find the comment thread that develops around an interesting post. So we created a Google Apps Ecosystem team Buzz stream for that very purpose.

Follow us on Buzz and share your thoughts in the comments!

We like shaking hands too

We love the Internet, but sometimes we would rather meet face-to-face. We do that too when possible. For example, we recently held a Google Apps Hackathon here in Mountain View, where dozens of cloud app developers, IT developers and systems integrators joined together to code and learn about Google Apps APIs.

We kicked of the day with great presentations by Jeremy Glassenberg of Box.net on their Marketplace app, and Chris McGarry and Neel Patel from Omnetic talking about opportunities for system integrators to build on and extend Google Apps. There was strong interest in the 9 short technical side sessions on many of our APIs, though a little less coding than expected. Our quick survey of attendees gave us some great feedback, so we plan on iterating and doing more in the future.

So please do reach out, both to us here at Google as well as your fellow community members, using these new virtual water coolers.

Posted by Scott McMullan, Google Apps Partner Lead

In the last 5 months, we've worked with over 150 companies who have launched apps in the Google Apps Marketplace. In our conversations with developers, marketing teams, and business execs, it's become clear we would all benefit from a wider conversation and debate -- beyond one-on-ones.

So we took the logical next step and created an email-based Google Apps Marketplace forum, and then embedded it in our documentation and program sites so it’s easier to find. Starting today, it's the best place we know of to engage folks in the Apps Marketplace community to discuss trends, pricing models, brainstorm features, or just gripe about stuff.

Join the forum and dive in!

But wait, there’s more

There’s a wider Google Apps solution provider community beyond Marketplace developers however. Google Apps resellers, integrators, and consultants are equally passionate about innovating with customers in the cloud. And here at Google, we’re growing an equally passionate team to work with you all, our extended community.

But our team has a problem: we have a lot of news and observations to share, large and small, but no good way to share them in a way that enables an easy conversation. You know, Twitter-style, but with the ability to actually find the comment thread that develops around an interesting post. So we created a Google Apps Ecosystem team Buzz stream for that very purpose.

Follow us on Buzz and share your thoughts in the comments!

We like shaking hands too

We love the Internet, but sometimes we would rather meet face-to-face. We do that too when possible. For example, we recently held a Google Apps Hackathon here in Mountain View, where dozens of cloud app developers, IT developers and systems integrators joined together to code and learn about Google Apps APIs.

We kicked of the day with great presentations by Jeremy Glassenberg of Box.net on their Marketplace app, and Chris McGarry and Neel Patel from Omnetic talking about opportunities for system integrators to build on and extend Google Apps. There was strong interest in the 9 short technical side sessions on many of our APIs, though a little less coding than expected. Our quick survey of attendees gave us some great feedback, so we plan on iterating and doing more in the future.

So please do reach out, both to us here at Google as well as your fellow community members, using these new virtual water coolers.

Posted by Scott McMullan, Google Apps Partner Lead

Want to weigh in on this topic? Discuss on Buzz