Microsoft provides a RESTful API for Exchange – Part 2

The boilerplate code we compiled in the first part of this walkthrough is clean and simple, but it’s only the basic stuff you need to get started, so we’ll be making some changes to this code to turn it into something to build upon. (The common Office 365 authentication bits don’t need changing, I’m thinking of the Exchange specific parts.)

First you can remove the stuff we don’t need, (it doesn’t break anything if you leave it there, so if you prefer to have the templated code there while we work that’s ok).
Delete the following files:
Views/ExchangeSample (folder)

Create a new class in the Models folder.

Type in or copy/paste the following code:

This should be the attributes we can expect for an email message. You’ll also notice I’ve tagged some of the properties with [ScaffoldColumn(false)] to avoid having them clutter up the view.

Next step is to create a new controller in the Controllers folder (I went with creating an empty controller).

As a starting point I’d like to retrieve all mails, and I feel that makes sense to put in the Index method.
Here’s what it looks like:

The parts of interest are:
requestUrl = “{0}/Me/Inbox/Messages” showing the folder structure of the server side.
“application/json;odata.metadata=full” meaning that I fetch everything in the message.

You might want to use odata=minimalmetadata instead to pull less bytes over the wire in some scenarios. (The original sample code does this as it only shows a few attributes from the messages.)

I also modified the route prefix for cosmetic reasons. To make that work you’ll need to modify RouteConfig.cs, and add a line of code:


Let’s scaffold a view, so that we’ll be able to see something sensible outside of the debug view:

I made a few modifications to the auto-generated code like removing Edit/Details/Delete, removing the Create link, and doing away with some white space. And to make it look less confusing I re-arranged some attributes too. (And there were a few attributes not scaffolded due to the structure of the json/model so I added those manually.)

I skipped the array attributes like ToRecipients, CcRecipients, and BccRecipients for now.

Could the CSS have been made way more fancy? Yes, probably. Do you really want all those mail attributes visible in a table? No, probably not. Do you really want to use a table for that matter? Well, it doesn’t seem entirely optimal with the default bootstrap at least.

But does it work? Yes, it does. Hit F5, sign in, and you should see a list of the mails in your inbox.

Note: if you have more than 50 items in your inbox, (and if it’s a real mailbox there’s a good chance you do), you will be capped at 50 items. This is not a bug, but it’s the size of the default set returned from the API. You can of course get all the mails you like, but you will need to implement the $skip parameter as a paging mechanism, and I haven’t done that here.

You will also notice that the body preview is plain text, whereas the body content is HTML. You can hack that by changing the table cell to <td>@MvcHtmlString.Create(item.body.Content)</td>, but since the HTML contains tags like it was a separate page that will mess up the layout for the entire page. You will need to fix that in a different way, so I’ll leave that be for now as well.

By now you should have a working web app (at least for scanning the inbox), and there really wasn’t much that had to be done in order to get there. Sure, there’s still stuff to do before it’s anything like a proper Outlook Web App experience, but the lack of functionality in this sample isn’t restricted by the API.

Leave a Reply

Your email address will not be published. Required fields are marked *