FYI: The Exchange Web Services Managed API is here!

As you might have seen, we announced last week that the Exchange Web Services Managed API is now available as a beta download.  I’ve been working with the API internally for about a year now and I must say, if you are writing .NET code that uses Exchange Web Services there’s no better way to do it.  I’ve been working on an Exchange browser application, similar to MFCMAPI which started out leveraging the auto-generated proxy classes.  Switching this project over to the EWS Managed API cut down hundreds of lines of code and improved the readability and organization of the code immensely.  (Stay tuned for more information on this project…)

From David Claux’s introduction:

“The EWS Managed API is a fully object-oriented API that provides the experience developers have come to expect from Visual Studio and the Microsoft .NET Framework. Built on the EWS XML protocol, it provides an easy-to-learn, easy–to-use, and easy-to-maintain .NET interface to Exchange Web Services that both beginner and advanced developers will find to be an improvement over autogenerated proxies.

Although the EWS Managed API is a new API (in the sense that it is a new .NET assembly that developers have to explicitly reference in their applications), it is important to understand that we are not replacing the EWS protocol. The EWS Managed API is just a complement to EWS for .NET developers. This means that your prior investments are safe. Whether you are using raw XML (if you are a Javascript developer, for example) or autogenerated proxies (on Windows or other operating systems) to talk to EWS, your existing EWS applications will continue to work. The EWS protocol is still the future of Exchange development; all new features will continue to be added to the EWS protocol, and will also be exposed in the EWS Managed API.”

The API at it’s simplest is just a set of proxy classes for interacting with Exchange – they still generate the same Exchange Web Services SOAP XML that the auto-generated proxy classes do or that your code that doesn’t use proxy classes do.  The difference is that this API is easy to use, understand, and has some additional business logic included.  The release of this API doesn’t change the support or our recommendations towards use of Exchange Web Services in their raw form.

Here are Matt’s three rules for getting started:

  1. Check out David Claux’s introduction for the API on MSDN as well as the “Working with…” section of the MSDN reference.
  2. Don’t confuse the Exchange Web Services Managed Reference with the EWS Managed API Reference.  The Exchange Web Services Managed Reference in the MSDN is reference of the auto-generated proxy classes.
  3. For the sake of my sanity please don’t start calling this the EWS MAPI – it’s the EWS Managed API, the EWS API, the EWS Client API, The API, Managed EWS, anything you want that doesn’t involve acronyms shared with other Exchange APIs.  (I guess I should be happy they didn’t call it EWS CDO, right?)

Comments