Posted on

Editor’s note: This can be a guest publish by Andrew Connell, Founding father of Voitanos. To learn more about Andrew, visit his website and follow him on Twitter: @andrewconnell.


Loudspeakers From Microsoft, Forrester, Mastercard, IAPP, CMS and much more!

Office 365, including SharePoint Online, is Microsoft’s enterprise collaboration and messaging platform. Countless companies use Office 365 for his or her company email, messaging, collaboration, intranets, and project management software. With the much company information and assets at work 365, developers being employed as employees or consultants for the organization, in addition to vendors, wish to leverage this data in custom applications to supply value towards the business.

The good thing is that Microsoft provides developers lots of APIs and SDKs to have interaction with Office 365 and related services… however that also presents challenging. Unless of course you understand the choices, you might not know the best idea one. It is just like entering a kitchen area with little cooking experience and getting someone say “grab a pot”, simply to see 10 different containers within the cabinet. Which is the greatest someone to saute vegetables?

In the following paragraphs I’ll cover the various Office 365 and SharePoint APIs and SDK possibilities to developers and a few scenarios on when for their services. While this information will not offer an exhaustive list, it ought to provide developers with a decent beginning point of the largest options.

SharePoint includes a couple of different choices for getting together with SharePoint. The following couple of sections will detail these options. However, prior to you buying one of these simple choices for your present project, make certain you browse the whole article because the Microsoft Graph section might be more relevant as to the for you to do.

SharePoint REST API

The main way custom applications happen to be speaking to SharePoint since SharePoint 2010 and SharePoint 2013 continues to be the SharePoint REST API. The SharePoint REST API provides developers use of not only the information within SharePoint site collections, sites, lists and libraries, but additionally towards the settings and configuration choices for these sources. Developers may even create content types and posts within the sites. Fundamental essentials most typical things, but

This can be a REST API that conforms towards the generally recognized ODATA specs for REST APIs. Therefore developers acquainted with the ODATA specs should they have labored with using other products, such as the format and grammar needs for queries in addition to how you can submit data, will feel at home dealing with the SharePoint REST API.

SharePoint Online, like several Microsoft Cloud Services including Office 365, is guaranteed using Azure Active Directory (also known as: Azure AD / AAD). Whenever a user accesses their mailbox as a swap Online or their company intranet in SharePoint Online, the initial step would be to authenticate with Azure AD.

The SharePoint REST API shares exactly the same authentication / authorization dependency with Azure AD meaning that each custom application must first be registered after which get the OAuth 2 access token from Azure AD that’ll be incorporated in each and every request towards the SharePoint REST API. Authentication in Azure AD is dependant on OAuth 2 and for that reason adheres to generally recognized industry standards.

This adherence to generally recognized open standards, both with ODATA for that format from the REST API and OAuth 2 for authentication, developers may use any technology stack, infrastructure and language they choose to talk with the SharePoint REST API.

For additional info on the SharePoint REST API, make reference to the state documentation on MSDN:

SharePoint SDKs (CSOM &amp JSOM)

Many occasions developers would rather make use of a software development package (SDK) rather of raw REST APIs. An SDK can rationalize concepts and simplify certain tasks for example authentication, or abstracting away the plumbing needed when creating REST calls.

When Microsoft shipped SharePoint Server 2010, they introduced a customer side SDK, known as the customer side object model (CSOM). The CSOM was supposed to have been employed for .Internet Framework authored applications located exterior to SharePoint. At that time, the CSOM provided more endpoints and abilities compared to SharePoint REST API.

In SharePoint 2013, Microsoft considerably committed to the SharePoint REST API and retooled the CSOM therefore it known as the remainder API as opposed to a dedicated endpoint. Which means that abilities from the CSOM and SharePoint REST API are mainly equal to today which is now lower to some personal preference by developers.

Such as the SharePoint REST API, the SharePoint SDKs are guaranteed utilizing the same Azure AD authentication flows, however they provide some functions to simplify the authentication process.

Microsoft also provides a JavaScript implementation from the CSOM, known as the JSON, which will probably be utilized by client-side solutions located within SharePoint.

For additional info on the CSOM &amp JSOM, make reference to the state documentation on MSDN: · CSOM: · JSOM:

Like that which you read? Make sure to sign up for our blog to remain in the fold for those things Office 365, SharePoint and much more!

SharePoint Search REST API

One special situation with regards to SharePoint may be the SharePoint Search REST API. Developers may use this to include search functionality to custom applications that support REST demands. The SharePoint Search REST API accepts queries using either the Keyword Query Language (KQL) or FAST Query Language (FQL).

Such as the SharePoint REST API, the SharePoint SDKs are guaranteed utilizing the same Azure AD authentication flows, however they provide some functions to simplify the authentication process.

For additional info on the SharePoint Search REST API, make reference to the state documentation on MSDN:

SharePoint PnP

An alternative choice that developers should know are sources supplied by the SharePoint Patterns and Practices (PnP) group. This can be a group operated by Microsoft which includes not only guidance documents, but additionally extensions towards the SharePoint CSOM and JavaScript libraries for developers. The majority of the operate in the PnP is dependant on originates from real-world customer interactions bridging gaps in on-premises SharePoint deployments to performing exactly the same tasks in SharePoint Online.

For additional info on SharePoint PnP and also the sources they provide, make reference to their subsite around the Office developer site:

Leveraging the strength of Office 365, search and cloud-computing, Microsoft introduced work Graph to reveal trends and relationships between people inside an organization according to their activity. I love to consider work Graph like a specialized “Office 365 insights search” service, one that you could only query.

Work Graph may be the engine that drives Office Delve. Delve helps people “discover new, relevant information and individuals in line with the intelligence of who [they] use and content [they] focus on.” (ref:

The 2 primary endpoints work Graph API offers are TrendingAround (products which are famous your circle of colleagues) and WorkingWith (people that you frequently communicate with). Additionally, it exposes an individual’s manager and assortment of colleagues.

Such as the other API options formerly covered, work Graph API is guaranteed utilizing the same Azure AD authentication flows, however they provide some functions to simplify the authentication process.

To learn more concerning the Office Graph REST API, make reference to the state documentation on MSDN:

Since I’ve covered the non-exhaustive list of the several Office 365 and SharePoint related API endpoints list in the following paragraphs, there’s one factor you should think about:

Ignore these except the SharePoint PnP one. Why?

Since the Microsoft Graph may be the single Office 365 API endpoint you need to consider first for your projects. The Microsoft Graph will probably be the main one endpoint for Microsoft Cloud Services, including Office 365 along with other services.

The Microsoft Graph enables developers to gain access to data from multiple Microsoft Cloud services including:

  • Azure AD (for users and groups)
  • Office 365
  • SharePoint Online
  • Exchange Online
  • OneDrive for Business
  • OneNote
  • Planner
  • Stand out
  • OneDrive Consumer

This single endpoint includes a couple of significant benefits of while using specific APIs offered by the formerly pointed out services.

First, it functions like a proxy to another endpoints behind it. What this means is developers don’t need to search for that different endpoints and documentation for every service. The Microsoft Graph includes a single, well-known, endpoint:

Second, since it is just one endpoint proxy to another services behind it, developers only have to register a credit card applicatoin once, users have to grant the applying consent once, and also the application needs to acquire a single OAuth 2 access token to speak to the different services.

Third, since it is just one endpoint, it may allow developers to navigate between entities and relationships even if they’re in various systems. For example, the Microsoft Graph will help you to obtain access to a person (from Azure AD) and find out their mail (from Exchange Online), notebooks (from OneNote), tasks (from Planner) and files (from OneDrive for Business). With no Graph, this could require five (5) different authentication prompts to acquire tokens for that different services and multiple round journeys towards the server to obtain the data.

Such as the Microsoft Cloud Services it exposes, the Microsoft Graph is OData compliant and leverages Azure AD for authentication. The Microsoft Graph also leverages work Graph API for relationships and insights between users.

In a nutshell, there’s hardly any need to use the specific Microsoft Cloud Service specific APIs once the Microsoft Graph has a lot to provide!

Microsoft Graph REST API

The Microsoft Graph, like other Microsoft Cloud Services, is obtainable with an OData compliant REST API. What this means is developers can leverage any technology stack, infrastructure and language to gain access to the Microsoft Graph endpoints.

Microsoft Graph SDKs

Developers preferring the SDK approach can be really pleased to realize that the Microsoft Graph also offers multiple SDKs for various platforms and technologies including:

  • Android
  • Angular
  • ASP.Internet MVC
  • iOS
  • JavaScript
  • PHP
  • Python
  • Ruby
  • Universal Home windows Platform (UWP)
  • Xamarin

The Microsoft Graph features its own, very robust site full of documentation, code samples, SDKs, along with a playground to understand more about its abilities with either test data or live production data out of your atmosphere. You will get more details concerning the Microsoft Graph at:

In the following paragraphs, I listed a few of the a variety of APIs and SDKs developers may use to produce custom applications. As the different Microsoft Cloud Services, including individuals within Office 365, have various REST APIs and SDKs, I suggest all developers to consider first the Microsoft Graph to find out if they are able to access and get what they’re searching to complete before searching in the service specific endpoints.

Web seminar

Want much more assistance with SharePoint personalization and SharePoint Framework? Join me for any web seminar at 2pm ET on Thursday, September 7 with AvePoint’s D’arce Hess to uncover guidelines and strategies for selecting the best API and/or SDK for the custom applications.