Microsoft Graph API (1) - 這啥?

Microsoft Graph API的前身叫做 Office 365 unified API。這什麼東西呢? 這是一套可以access Office 365中各種服務的資料的API，簡單一點說，就是透過這組API你可以存取O365中用戶的資訊。

你看到unified這個字眼，可能會猜測，那它出現之前，可能有一個比較不unifie的API囉?

是的，你沒猜錯。

這一段路是有一個演進的過程的，我們先來介紹一下，我嘗試說個簡易版的故事。

首先，會接觸到這個API，是一年多以前的事情了，那時Office 365開始在台灣推廣，我們需要撰寫一些程式碼來存取O365上的資訊(像是用戶身分、行事曆、檔案…等)。

那，微軟這麼大的軟體公司，應該會有提供一套什麼API來存取這些資訊，用起來應該很簡單，對吧? 如果你這麼想，那就…稍微天真了。

提供API是有的，但你會好幸運的發現，不是提供一套API，是好幾套API。為何呢? 因為本質上Office 365根本就不是『一套』軟體。

什麼意思? Office 365，其實一堆軟體服務(SaaS)的集合，請記得這一點，它不是一套軟體，它是一群軟體所形成的一個平台。例如Office 365中的檔案，其實是Onedrive特殊版，筆記本是OneNote，email、行事曆是Outlook，通訊錄要看你想要抓哪種，有AD的，有email用的…這，還只是個開始。

如果你觀察Office 365，你會發現他一直在長大，最近還推出了Planner、Power BI、Flow …等等等、等等等。聽說以後還要推出類似Slack的Skype Team，總之Office 365跟你想的可能不一樣，它並非是一套軟體，他是很多套軟體服務。

而這很多套軟體服務的網址(網站)根本不同，只是每一個網站之間用oAuth做單一登入(SSO)的身分驗證而已，讓用戶用起來『像是(但根本不是)』在同一個網站裡面，但其實你是在多個網站裡切來切去。

那，這就讓developer很頭痛了，因為你以為的『抓取Office 365的資料』，其實不是在跟一組API打交道，是跟一群API打交道，每一種API都有自己的呼叫方式，都要做一次身分驗證，每一個驗證都要先取得授權，這…也太痛苦了吧。

寫到這邊，你就該知道unified 的必要了，這也是Office 365 unified API誕生的原因，後來隨著時間，他改名叫做Microsoft Graph API, that’s it.

參考底下這張圖:

可以這麼看，Microsoft Graph API是一個入口，讓你的應用程式可以簡單的面對一組API，做一次身分驗證和授權，讓你的日子好過一點。

可以想見，隨著Office 365家族中的Apps越來越多，越長越快，這組Graph API也會持續成長和更新，你現在看到的有 v1.0和beta兩個版本，抓取到的資料有所不同，適用範圍也各異。現在，你可以透過Graph API存取到底下各式各樣的用戶資訊:

不難想像，在企業中除了ERP以外，其他影響企業營運與命脈的資訊，現在全都在Office 365當中(只要你是用戶的話)，我曾經勸某一個正在開發協同運作的團隊說，如果你想靠協同運作來掙錢，得要好好想想了。O365在協同運作的領域雖然不算是無敵，但它天生擁有的資源和富爸爸，讓其他產品很難很難超越。

況且微軟似乎還不滿足現狀，發展不僅止於此，Planner和傳說中的Skype team的出現，都意味著O365現在還只是個基礎而已。

這也暗示著，掌握Graph API，對建立企業運作相關加值軟體服務的重要將不言可喻。OK，我們將在接下來幾篇文章當中，開始討論如何使用此API，以其所能達成的效益。