Those of us who lived through the dark years of SharePoint 2010 will remember the pain involved in trying to federate out content into third party applications. Authentication was hard to set up, documentation was baroque and feeds were formatted in a strange, bloated XML. Getting any of it to work in a non-Microsoft environment was to all intents and purposes impossible.

However, Microsoft has promised big improvements to its APIs in the latest versions of Office 365 (Microsoft’s cloud platform for productivity software). You should now be able to create an application that authenticates a user and then generates content based on the content of their email, calender and contacts really easily, and in the platform of your choice (so long as you choose Android, ASP, iOS, Node.js, PHP, Python or Ruby), the application in question should then be able to run completely independently of Office 365.

This sounded promising, so I decided to give it a go. On Linux. Because I like a challenge.

The Documentation

Googling “Office 365 API get started” yielded a well explained page that described the APIs available, let you try them on test data, and then by simply logging in to your Office 365 account, it let you start testing against your actual data. All of this Actually Worked™. Nice.

Microsoft’s “Get started with Office 365 APIs” page

The APIs

APIs are available for Calender, Email and Contacts. Each is presented in a relatively lean JSON format that uses an intuitive URL endpoint. For simple reading of data its certainly very straight forward and a big improvement on previous web services. The surprise was that there were no surprises. So far so good.

Generating an example project for Node.js

You could simply choose “Node.js”, write in the name of your app, and a downloadable bundle was generated. Confusingly though, it told me that “your project is on its way from GitHub”- surely GitHub clone instructions would have been more appropriate? Once download and unzipped, npm install had no effect since there was no package.json. You needed to know that you had to do npm install simple-oauth2 and npm install node-outlook to get things work as expected. Since there were no version numbers specified, the modules are likely to become incompatible under version creep- this could be a source of “ouch” in coming months. Other than that though, things seemed to work as intended. Typing node index.js started an http server, which provided a login link that when authenticated brought up the raw contents of my Office 365 Outlook inbox, and all of this worked uncomplainingly on my venerable Ubuntu box. A bit rough around the edges, but fundamentally a good developer experience.

Conclusion

At a first glance the new APIs for Office 365 seem to be quite usable for node.js applications. Gone is the clunky formatting, the challenging authentication, and the Microsoft lock-in. My only slight concern was the deviation from standard node.js practices: the structure of the sample app was unusual and some judicious sprinklings of git and npm would have negated the inevitable problems that will arise due to lack of version control. These are of course peripheral issues that affect the examples more that the actual APIs themselves, but they are still slightly jarring.

That said, Microsoft deserve some respect for the direction they are taking with their cloud offering. Gone are the days of the walled garden: you can now use Office 365 as a back end for any standalone application, on any operating system. So how good are the Office 365 APIs for Node.js? On the face of it- quite good.