This post is the third part of a series of posts chronicling my (mis)adventures learning Python and Django, and using them to integrate with Office 365. This extends the sample app from Part 2 to add CRUD operations with the Mail and Calendar APIs.
I had so much fun making part 1 and part 2 of this sample, I figured why not take it farther and implement a bit of all three of the Exchange-based APIs? In this post, I take on the Mail API and the Calendar API.
Paving the way
My plan was to extend the existing o365service module to include Mail and Calendar functions. But before I started, I decided to try to streamline the existing code a bit. To that end, I added a make_api_call function to the module that handles setting headers and sending the HTTP request. I updated all of the API-specific function like create_contact to use this function.
Being a good citizen
Since all of my API calls are now going through the make_api_call method, I figured this was a good time to add client instrumentation. Now each request’s id is written to the debug log. If this was a production application and I needed help from Microsoft to figure out why calls were failing, this forensic data could help expedite a resolution, so it’s definitely a recommended practice.
Enable Fiddler capture
Another small change I made while consolidating the HTTP code was to add a global flag to turn off SSL certificate validation. While developing part 1 and 2, I was never able to get Fiddler captures of the calls made by my app. With Fiddler running, I would always get SSL certificate validation errors. It turns out that the requests module will fail requests when the SSL certificate isn’t valid. Of course that’s a good thing, but it makes it difficult to use Fiddler. No problem though! The requests module has the ability to suppress SSL certificate validation on a per-request basis. If you want to use Fiddler, set the verifySSL variable at the top of o365service.py to False.
Adding the APIs
Adding the Mail and Calendar APIs was fairly easy since I had the Contacts API functions as a starting point. Copying those methods and making a few tweaks was really all it took. The function create_message isn’t very different than create_contact. You gotta love REST. I won’t go into detail here, the relevant changes are all in o365service.py.
Invoking the new APIs
If you look at the 1.2 update on GitHub, you may notice that there are no new views in the app. That’s right! I didn’t change the UI of the app to use these new APIs. Instead, I wrote tests. Django has a neat testing framework. I created the MailApiTests and CalendarApiTests classes, and threw in a ContactsApiTests class for good measure. What I like about the way Django testing works is that I can easily invoke all tests with one command, or I can be selective. For example, I can run all of the Mail API tests with this command:
python manage.py test contacts.test.MailApiTests
Or, I can just invoke the test_delete_message test with this command:
python manage.py test contacts.test.MailApiTests.test_delete_message
You have to manually copy a valid access token into test.py to get these tests to run. If you use the app up to the point where http://hostname/contacts will display a list of contacts, you can browse to http://hostname/admin, login as your superuser, and copy the access token from your Office365Connection record. Keep in access tokens expire after an hour.
Some of you may have noticed that the o365service module doesn’t cover everything. For example, you can work with contacts, but not with contact folders. Messages are there, but not mail folders. Or more subtly, you can get messages from the Inbox, but not from other folders. So what if you want to do more? The make_api_call method can help here. You can add another method to the o365service module, or you can call make_api_call directly! As an example of this, I use it in the test_send_draft_message test to get the messages from the Drafts folder.
This will likely be my last post in the Python series. I’ve had a blast playing with Python and Django, and they seem like a natural platform for consuming the Office 365 APIs. As fun as it’s been, it’s time for me to move on to another language. What will it be? Stay tuned to find out!*
*Probably Ruby. However, I’d love to hear suggestions from the community. Is there a language or platform you’re dying to see the Office 365 APIs run on? Drop a note in the comments.