The three new Microsoft Exchange APIs can handle more than just emails, are more open-standards friendly and based on REST, and are simpler to use than EWS.
For years, developers who wanted to work with content in Exchange mailboxes had many choices available to them. RPC/DCOM, Exchange MAPI, Outlook MAPI, and WebDAV were all heavily used from Exchange 2000 up through 2010. Starting with the 2007 edition, developers also had Exchange Web Services (EWS) to work with, and of course, since Exchange 4.0 there have always been the tried and true legacy protocols of SMTP, POP3, and IMAP. But despite all these choices, there have been some challenges.
With each new version of Exchange, we have seen some of the older Exchange-centric protocols go away. Even as developments in Outlook client access protocols proceeded, bringing us first RPC/HTTP, which we all know and love as Outlook Anywhere, and then MAPI/HTTP, the older protocols developers have relied upon for years continue to die off. First RPC/DCOM and WebDAV went away, then Exchange MAPI, and today even OA has been deprecated, with MAPI as the new king of Outlook client protocols. Even when they were available, the more Exchange-centric protocols were all proprietary. Still supported today, the legacy protocols can only deal with mail items.
More options to handle content
But developers who want to create client applications or connect their other applications to Exchange mailboxes should take heart, as there’s a new API in town, and it promises to fix a lot of the shortcomings of the earlier protocols. The Exchange Team announced at Ignite and on their blog that a new set of APIs will soon be available for both Exchange 2016 and Exchange Online, and they are based on REST standards.
Three new APIs in total will soon be available: one each for mail, calendar, and contacts. They will leverage open standards for connectivity and authentication, including JSON, OAUTH, and ODATA, and there are SDKs available for practically any popular development platform in use today. Whether you are coding a server interface, a client app for the web, or for a mobile client on iOS or Android, you’ll be able to take advantage of these new APIs. SDKs exist already for iOS, Android, NodeJS, Ruby, Python, and of course .NET.
It’s a pretty safe bet that this is the future for anyone looking to develop connections to Exchange Server, whether on-premise or in the cloud. The APIs not only are standards based, but are designed to ensure customers in a hybrid configuration, with some users on-premise and some on Office 365, can create apps that work regardless of where the mailbox is, and that won’t require the end user to do anything if a mailbox moves. They have also already put up a great deal of documentation, as well as an OAuth sandbox for developers to start playing with.
New references for greater flexibility
Here’s some of the online references you will want to have, or share with your dev team.
Mail API reference
This is where you will want to start, since even the most basic app will need to work with mailbox content.
Calendar API reference
Whether you want to view a schedule or create entries, the Calendar API is how to work with calendar items.
Contacts API reference
Address book lookups as well as the maintenance of shared and personal items will leverage this API.
Groups API reference
At present, Groups is only an Office 365 construct, so don’t worry too much about this (for now) if you are not looking at the cloud. However, it may be ported back to on-premise installations, or you may find yourself in the cloud sooner or later, so be aware of this as Groups may be the next big thing in collaboration.
Other V2.0 APIs
There’s some cool stuff in here, particularly around notifications, user photos, etc.
While all of this is probably safe to consider in preview for now, these include Tasks and Batch APIs, the former of which may be useful for client apps while the latter has admin written all over it.
This is a good page to book mark as it has a lot more detail on all of these APIs.
Outlook OAuth Sandbox
Here’s a safe place to start playing with your calls.
The new APIs will also require /api, a new virtual directory under Exchange. If you are using reverse publishing, make sure that vdir is allowed. You will also need to ensure that your Autodiscover FQDN is resolvable through DNS both internally and externally. That’s probably another sign of moving to more standards based approaches, since just looking things up in AD is not going to be enough to use the new API, even though you’re internal.
Whether you code yourself, or have colleagues who do, if you have any custom developed apps that need to interact with Exchange, you want to start looking at these new APIs now. Odds are good anything legacy will be going away sooner rather than later.
If you are a dev and have started to work with these, please leave a comment below and let us know what you think. Does it look like these will make your life easier, or harder, or is it too early to tell? Thanks!