Microsoft provides a RESTful API for Exchange – Part 1

I don’t remember exactly when, but it must have been about two years ago I was struggling implementing a scenario where an app on a device was to retrieve calendar entries from an Exchange Server. Implementing Exchange ActiveSync (EAS) wasn’t really interesting in this scenario since the intention wasn’t creating an email client; only calendar was interesting at first. Possibly contacts later on.

Exchange Web Services (EWS) seemed like a better option for this. And for the functions required it was. But there was a snag or two with how EWS worked. Authentication was username/password-based (which is ok), but didn’t support tokens or federation in any form. So, even though a previous step in the app had full integration with Azure ACS and ADFS on-prem this token couldn’t be reused against the EWS virtual directory. The username/password had to be stored in the app which wasn’t optimal in this case. In addition the EWS API is an asmx-style web service which can be a hassle to work with sometimes. Sure, both obstacles could be handled, but didn’t provide quite the experience you would want neither for developer nor end-user.

When I started hacking together my EAS RESTful API last year I tried to make at least one part of it easier. The authentication bits I have skipped so far, as there is no clean way to make the EAS virtual directory accepting tokens directly. (This wouldn’t be part of the back-end API I have running in Azure already, but I was thinking about storing credentials in a db, and using a passive federated login for the front-end itself.)

(If you want to read up on this project:
http://mobilitydojo.net/2013/06/24/rest-based-api-for-exchange-activesync/)

Now, it seems someone at Microsoft has also been thinking along these lines, and they’ve released a preview of REST APIs for Office 365. It’s RESTful, and it does Oauth, so it certainly is taking away some of the dev pain.

It’s in a preview state, so it’s not a full replacement for an actual EAS/EWS implementation yet, and there’s probably bugs and whatnot too. But I thought I’d take a quick walkthrough of what it can look like.

Read more

EAS Web API – Status 28. February

Another month, another release. At least I’m keeping it alive I guess 🙂

No big things this time either:
– I rolled up NuGet updates.
– I changed return types from List<x> to IHttpActionResult (as I mentioned last month I might do). Haven’t gone async yet since I want to go over the rest to see it’s “proper” async if I go that route, but it’s a start.
Nothing magic comes of this as such, but it lends itself to cleaner REST-like behaviour with

return Ok(items);

instead of

return items;

(Silly example I suppose – maybe

return InternalServerError(); 

is a better example.)
– Cleaned up some return values; so for instance instead of an empty JSON object "[]" when no results are found HTTP 204 (No Content) is returned.
– Started implementing the “SendMail” command (not completed yet).

I was made aware of an issue with my conversion from XML to JSON when it comes to contacts. It seems there are cases when the Contact objects are not serialized correctly on my end, so it ends up with a mixing attributes from one contact with another… Yeah, you could indeed call that a nice little bug. So, I’m going over the code there to see what I’m not doing right. (Probably something minor, but my XML parsing isn’t what you would call optimal.) I don’t know yet if this is something impacting other item types as well.

As usual the code is on http://easweb.codeplex.com
and the test site is on https://easweb.azurewebsites.net

EAS Web API – Status 31. January

Fairly minor update this time (as well). Visual Studio 2013 Update 1 was just released, and with it a couple of upgrades to the usual suspects in NuGet.

So I’ve done all NuGet updates including Web API 2.1 and MVC 5.1. (Bunch of other related ones to of course like jQuery, etc., but they’re pretty much the same with my limited UI.)

I’ve also enabled XML documentation generation for the API Help Page. If you open the solution in Visual Studio it’ll spit out about 80 warnings that not all public classes and methods are documented, and I might get around that by just stubbing out something to make it stop complaining. In the meantime I have documented the API controllers, which looks nicer even though they feel mostly self-explanatory.

I haven’t documented the properties of the items returned as these are in a different solution (and as such wouldn’t be included anyways even if I did decorate them). I’m considering whether I should add a ViewModel on top of the models though.

I was looking into Attribute Routing as well, since I’ve been quite happy with that technique in a different project I’ve been hacking on. But it seemed to be better to combine that with some other restructuring. (Going with public async Task<IHttpActionResult> instead of public List<x> perhaps? Although documentation works better if you know the exact type of object you get in return. Hmm…)

As usual the code is on http://easweb.codeplex.com
and the test site is on https://easweb.azurewebsites.net