Each of these different Office 365 APIs, including the Unified API, have native SDKs as well as raw REST APIs. The Office 365 team is moving fast and releasing things as they are available, so which APIs and SDKs are available for each endpoint vary. (But they all include a REST API.) The native SDKs wrap the REST APIs in a fluent API that some developers prefer. In a show of their openness in the Office 365 platform, you will find native SDKs for .NET, iOS and Android, as well as cross-platform SDKs for Cordova and Xamarin.
There is one very important aspect that I have not addressed so far: app identity and authentication. Office 365 uses Azure Active Directory (AD) as the storage mechanism for all users and applications deployed to Office 365. It relies on Azure AD to handle all authentication and app permissions. All the Office 365 APIs require that developers create applications in Azure AD and give those applications access to the different endpoints, granting granular permissions to each application. These applications can have both delegated permissions, where both the application and user must have the necessary permissions; or application permissions, where the application can impersonate a user or authenticate without user involvement.
Azure AD implements the popular OAuth 2.0 Web standard authentication protocol. This protocol supports multiple options for authentication, referred to as OAuth flows. These include the Authorization Code Flow where users authenticate with Azure AD and provide a token to the application or SharePoint Add-in that is used to obtain an access token (the key used in all Office 365 APIs).
Another option is the Client Credentials Flow, which allows developers to create applications that have app-only permissions that can authenticate without user involvement or elevate the permissions of the current user.
Finally, Azure AD also supports Implicit Flow, which facilitates pure client-side applications such as the popular single-page app model of development.
At the time of this writing, there is a little confusion about where SharePoint Add-ins reside: Do they live in SharePoint or Azure AD? When SharePoint 2013 was introduced in Office 365, Add-ins and their permissions were stored using Azure’s Access Control Service, but that has since been deprecated in favor of Azure AD. Microsoft is working to converge all SharePoint Add-ins to Azure AD and into a single Add-in registration portal. Stay tuned for more information on this throughout 2015.
Microsoft has made significant strides with Office 365 development opportunities for SharePoint, Exchange, the Office clients, as well as custom Web applications that leverage Office 365 data. Developers have many options available to them in creating custom applications. This is just the tip of the iceberg too as Microsoft and the Office 365 team are constantly improving upon their investment and introducing options for developers.
One of the hardest things is staying on top of everything. The best place to get the latest information is at dev.office.com. Here you’ll find documentation, articles, news and tons of free training opportunities from the Microsoft Virtual Academy and code samples found in its quickly growing organization on GitHub.
In addition, the Office 365 Developer team announced in April a new venture: the Office 365 Developer Program. Developers can sign up for free to get a monthly newsletter on the latest changes and improvements, as well as to get access to special deals, meetings and webinars from third parties.