Integrating your App with the productivity app suites of Google, Microsoft or Apple is getting more and more important. In the following I will compare the different APIs of Google, Apple and Microsoft by discussing the APIs you would need to build a typical Todo App in a hyperintegrated manner. I am looking at the specific APIs that are offered and show what is possible today and what is missing.
When we talk about hyperintegration, we have the following two scenarios in mind:
It "uses" the data of a third party app directly without any sync- or import-/export- functionality. It directly reads and writes from/into the database/-storage of the third-party app (typically through an API). Example: A CRM app that does not store the contact information in its database rather stores contacts in the (third party) contacts app of the user.
It inserts new user interface elements into the user interface of the app or service it is hyper integrated with. Example: A social media app that shows additional information on contacts right in the user interface of the (third party) contacts app of the user.
Hyperintegrated Todo App
Let’s imagine a very simple Todo-Application. Next to the entities that are typical for such an application like the user, the todos themselves we also want to setup due-dates, assign tasks to contacts and send messages.
And we might go a bit more sophisticated and start to read the users emails and create todos out of them. But let’s keep it basic.
The next step would be to come up with a very rough ER-Model, which could be layout like the following:
As we can see, the due date is stored in the calendar-event-entity, the assigned contact details within the contact-entity, the original message details in the corresponding message entity and for the user details we will rely on the google user himself.
By the definition above that would be hyperintegrated. We wouldn’t duplicate any data of the used APIs within our app-specific datastore.
So how are the three different APIs comparing?
Google APIs
Looking at the possibilities of google’s APIs and assuming the targeted user is a Google user, the only thing we need to store on our end would be the todo itself. And we need to store several references to other entities, like calendar events and which we might assign the todo to contacts.
So let’s see what google has to offer here. Selecting and finding the right APIs at the google developer console is quite fun and can be overwhelming since google offers nearly everything you might need. (https://console.developers.google.com/apis/library)
For our purpose we will look at the following APIs:
OAuth 2 (https://developers.google.com/identity/protocols/OAuth2) Google APIs use the OAuth 2.0 protocol for authentication and authorization. Google supports common OAuth 2.0 scenarios such as those for a web server, installed, and client-side applications.
Google People API (https://console.developers.google.com/apis/library/people.googleapis.com) The People API lets you list and manage the authenticated user's Contacts and retrieve profile information for authenticated users and their contacts.
Gmail API (https://console.developers.google.com/apis/library/gmail.googleapis.com) Read and send messages, manage drafts and attachments, search threads and messages, work with labels, set up push notifications, and manage Gmail settings.
Google Calendar API (https://console.developers.google.com/apis/library/calendar-json.googleapis.com) The Calendar API lets you display, create and modify calendar events as well as work with many other calendar-related objects, such as calendars or access controls.
In terms of what “hyperintegration” means to us, we get everything we need. You also might notice the Google Tasks application which has its own REST-API. For the sake of this example, we would leave this untouched and proceed with our very own tasks/todo application.
Microsoft API
The Microsoft Graph API offers a single endpoint, https://graph.microsoft.com, to provide access to rich, people-centric data and insights exposed as resources of Microsoft 365 services. You can use REST APIs or SDKs to access the endpoint and build apps that support scenarios spanning across productivity, collaboration, education, security, identity, access, device management, and much more.
Graph Security API (https://docs.microsoft.com/en-us/graph/security-authorization) Security data accessible via the Microsoft Graph Security API is sensitive and protected by both permissions and Azure Active Directory (Azure AD) roles. It’s basically an OAuth 2.0 flow curried with some extra juice of microsoft’s Active Directory.
Outlook Outlook is a messaging communication hub in Office 365. It also lets you manage contacts, schedule meetings, find information about users in an organization, initiate online conversations, share files, and collaborate in groups. So for all our needs we find the APIs on this end:
As we can see, Microsoft is giving us a great time by offering everything we need a straight and modern fashion. For me personally, it was really fun to play around with the Graph Explorer and investigate the most complete documentation.
Apple APIs
If you looking for some similar APIs (as of Google and Microsoft) for iCloud you might be disappointed. Officially there is no one-stop shop API experience for the developer. What we need to do is to implement a lot of things on our own, and we do not have a place for storing the user’s authorization data as well. Nevertheless, there is also no clear way described to write to an iCloud - Calendar without being an iOS-user and following a very uncommon sharing mechanism.
The official supported super-inconvenient way by apple would be to use:
Apple JS Login Thankfully, Apple adopted the existing open standards OAuth 2.0 and OpenID Connect to use as the foundation for their new API. While they don’t explicitly call out OAuth or OIDC in their documentation, they use all the same terminology and API calls. This means if you’re familiar with these technologies, you should have no trouble using Sign in with Apple right away! But where this is also the gateway for services on google or Microsoft to get the user’s consent for other scopes like mail, calendar, contacts - at apple this just gives you the users name and his email address. Bummer, isn’t it? Hopefully, Apple will develop this further and come out with a great new and shiny API in 2020.
CalDav for the calendar? Search around the Internet for how to get this running, I was giving up after hours. You can read the users calendar when its public and you’ve got the calendar-URL. But for write access, there is currently no way around to have an iCloud-User account. Bummer, again! There are alternatives which aren’t supported officially by Apple, we will come to this point.
IMAP for mail? Similar to the calendar capabilities there is no REST API for accessing messages. The Developer of a web app is left to use the good old IMAP protocol. Bummer #3!
what about contacts? The only way I found to access the user’s contacts was either by building an iOS-App or to build an native desktop app.Anyway even there would be a possibility - I think it’s safe to say: “it’s very hard to find”. Bummer #4!
I don’t want to get into this too much, but it looks like that Apple isn’t taking much care about web developers or just has a totally different view on those things that are common for the “modern” developer. As far as I can tell, the apple iCloud APIs is pretty much nonexistent and the other APIs that are offered are 95% out-standard.
All that Apple needs to do to make us happy is to publish its private iCloud-APIs they are using on icloud.com. Luckily there are other engineers out there. Some of them did the hard work to reverse-engineer the hell out of iCloud. ( https://www.npmjs.com/package/apple-icloud )
Conclusion and Outlook
Its safe to say that our Todo-App could be integrated in a hyperintegrated manner, using Google’s and Microsoft’s APIs. Sadly Apple seems to be the only kid in town that rides the short bus. Maybe I did get that wrong, then please correct me, but anyway I hope that they come up with a new and shiny API in 2020.
The Apple JS login seems to be the very first step in the right direction and am really convinced that they will come up with something great next year.
Preparedness for hyperintegration: Google A, Microsoft A+, Apple D.