INTRODUCING REMOTE APIS IN SHAREPOINT 2013

When SharePoint first started gaining traction with users all across the world around the year 2002, the product was very different than the developer friendly platform it is today. Initially, SharePoint wasn’t built with developers in mind. It didn’t offer good extensibility points or customization techniques, which lead to people’s customizing SharePoint in unsupported and often fragile ways. Microsoft heard loud and clear from people all over the world that they wanted to be able to do things such as change the branding and make templates for parts of SharePoint. As a result, releases such as SharePoint 2007 and the move from ASP to ASP.NET represented great steps forward, and new options for extensibility emerged. People were able to build Web parts and had access to SharePoint’s Server-Side Object Model (Server OM) that allowed them to call into SharePoint data and perform operations programmatically. These features enabled developers to build solutions of all kinds. However, this code that leveraged the Server OM ran as part of SharePoint’s processes. The code would load within SharePoint, which made it vital to ensure that it was of high quality; otherwise, the code could adversely affect SharePoint. Issues such as high memory consumption and high CPU load became prevalent. In fact, Microsoft has often acknowledged that many of the critical support issues customers raised with them had their root cause identified as issues with custom code in the SharePoint process. This was, of course, not a good thing for SharePoint’s image and reputation. Matters were further complicated by the fact that, at times, the Server OM was hard to use. For example, developers needed to know how and when to dispose of objects correctly. Not doing so could lead to high memory consumption. Conversely, disposing of the wrong thing could cause crashes.

Additionally, SharePoint has for some time provided a set of SOAP-based Web services that enable users to do some, but by no means all, of the same things the Server OM provided. These Web services revolved around sending and receiving a SOAP-formatted XML payload to and from SharePoint. These services have not stood the test of time well though. They are bulky and cumbersome and have been in dire need of an upgrade.

In the SharePoint 2013 release, those same Web services exist for backward compatibility. In fact, in SharePoint 2013 Microsoft has signaled it is deprecating these older SOAP-based services, which means you are unlikely to see them in future releases. Deprecating is a warning to stop using these services and to start thinking about shifting your code to the newer, more modern APIs.

Because the Server Object Model and the SOAP Web services are the two main APIs available for programmatically integrating with SharePoint, and because both of these options have significant drawbacks in their approach given modern recent developments in API and protocol design, SharePoint 2013 addresses these issues head-on. The new release of SharePoint provides a new, consolidated set of APIs for developers based on newer Web standards and modern coding practices, and targets integration scenarios that are the most prevalent and common. For developers who build solutions that integrate with SharePoint this is good news.

The rest of this chapter is dedicated to walking you through SharePoint 2013’s API improvements, assisting you with learning about them, and providing guidance on where and when to use them.