EAS Web API – Status 31. December

As per usual at this time of year there’s a lot of things to wrap up before the year ends, and December is a busy month. This year was no exception – lot’s of Windows Phone coding fun, been deep digging into Windows Azure Active Directory (haven’t blogged about these topics yet though), and I even managed to squeeze in two certification exams (so I’m finally an MCSD in Web Applications).

Things have been slow on the EAS Web side; not only due to lack of time, but I also felt it might be an idea to go through the Web API stuff I had to do for the exams to see if there was something I was doing plain out wrong and should rethink.

The main issue on the to-do list from the last commit was to do an upgrade based on Visual Studio 2013 having been released. So the change list is rather short:
– Upgraded to MVC5 and Web API 2
– Applied all available NuGet updates.

The upgrade process isn’t entirely automated and there’s a few additional changes needed, so for the manual steps involved look into this article:
How to Upgrade an ASP.NET MVC 4 and Web API Project to ASP.NET MVC 5 and Web API 2:
http://www.asp.net/mvc/tutorials/mvc-5/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2

Of course if you just pull down the changes from Codeplex that doesn’t matter.

Now, if you create a new Web API or MVC project from scratch in VS 2013 you’ll get a decent layout based on Bootstrap. This isn’t included when upgrading, so you could say it still has the feeling of VS 2012, but I felt this wasn’t really an important issue to fix right away. (I’ve been tinkering with Bootstrap on an unrelated MDM project, and I’m liking it so far.)

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

Happy new years!

EAS Web API – Status 30. October

It’s been quiet for a while now on the EAS Web API front, but I’ve been doing some work behind the scenes. I wouldn’t say I’ve implemented any major features this time, but I have done some rework architecturally that I hope will make it easier to build on going forward.

I have so far put a lot of logic into the controller in the Web API project, and this was a simple way to get things into a test-friendly state. Unfortunately it also meant replicating a lot of code unneccesarily, and make re-use less accessible. So, I moved most of it out of the controllers and into the EAS Protocol instead in this release. It shaved off a lot of lines of code and that’s a good thing.

Initially the EAS Protocol namespace was implemented as a Portable Class Library as this seemed like a sensible thing to do at the time. When I moved lots of code from the controllers things started to break because there was a lot of the code that did not use .Net assemblies suitable for PCL use. I looked at rewriting it, but I concluded that it was way more work than I was willing to commit for something that was really more of a nice-to-have than need-to-have. I’m expecting it to be simple to re-use code between Web and something like a Windows Store app without PCL as well. Possibly not SilverLight, but let’s be honest; SilverLight has some other challenges ahead of it…

This means that I also see the EAS Protocol library perform more work and I’ve started implementing the different parts of the EAS protocol as different classes – like AS-CMD, AS-xyz, etc. We’ll see how that works out.

For completeness sake I also added a Notes and a Task controller even though they’re not all that useful.

I’m seeing some issues implementing the action for getting single mail items, but I’m sure that’s just me missing something obvious that will stand out when I revisit the code. So there are bits included that are known to not work as intended.

The thing that has held me back a little bit regarding actually hacking away at the keyboard is that I want to move the code base to use Visual Studio 2013. Now there’s nothing wrong with 2012 – I like it a lot, but with 2013 comes Web API v2 and smooths out some things regarding building APIs. CORS support goes RTM instead of the preview bits I’ve got now. There’s also other features that look like they’re just making the VS experience itself slightly improved. There should be solution and project cross-compatibility between the two version of Visual Studio as well so hopefully it’ll still work in VS 2012. (I really don’t know if there are features that are able break the build.)

And of course it’s still located at http://easweb.codeplex.com

EAS Web API – Status 26. July

July’s a slow month with holidays and everything coming with that. While it would seem to be a perfect time for getting things done that’s just not how it turns out 🙂

I’ve snuck in a few updates to my RESTful EAS API though. I’ve added email support (just metadata to start, but I’ll add full mail fetch soon), and in that process I uncovered a bug with the WBXML decoding (being able to parse blobs) which had to be handled first.

I’ve also added CORS support which you’ll definitely want if you’re using JavaScript. The support for this is in a prerelease state from MSFT so mileage may vary, but I thought it was a good thing to include nonetheless.

This means it’s sort of functional now although I’ll have to do some polishing and add things like fetching entire calendar items and not just the truncated versions.

I’m also not entirely sure whether to add support for "Tasks" and "Notes". Notes is kind of being phased out (use OneNote instead), and I’ve never been a big fan of the tasks in Outlook either. But at the same time – if I implement an API I should include everything for completeness sake… It’s probably not that heavy lifting to implement (at least just the basic GET-ing) so unless it brings new issues with it it’ll probably be there.

Another not entirely unimportant issue is that I have no problems acknowledging that the documentation section on Codeplex is sparsely populated at the moment. I hope to improve this further in the next weeks.

So, head on over to https://easweb.codeplex.com and fetch yourself some code 🙂