The write up from my SPC14 session (Deep Dive: REST and CSOM comparison) is posted here: http://blog.mannsoftware.com/?p=1521. I’m a little late getting this posted here (the post itself has been up for 2 weeks), but I wanted to make sure to point folks to it as I mentioned I would during the session. Also, if you’d rather watch the session recording, it is available here: http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC423.
Rather than just summarize the session in my post, it’s actually a full write up of everything I covered in the session, plus a little bit more that didn’t fit in the time allotted for the presentation at SPC. So I cover all of the elements that are important to consider when you’re choosing an API in order to access SharePoint from off-server:
- Technology Concerns
- Intellectual Property Protection
- Developer Concerns
The overall takeaway from the session is that there is no clear winner for all situations. Depending on your particular situation, one API (REST or CSOM) might be better for you, and I lay out what those factors and situations might be. For example, I talk about the fact that if you are accessing certain aspects of SharePoint (namely workflow and managed metadata) you have to use CSOM as there is NO REST option for those things.
Technology Concerns covers things such as the server or operating environment your code is running in, the role SharePoint was playing in the application, how you were deploying your code (CAM vs. FTC) and a few other factors that are largely unchangeable so they can often play an important role in choosing your API.
Performance was an interesting discussion point. As expected, REST was exceedingly chattier than CSOM, but it also outperformed CSOM in total elapsed time for my tests. Each CSOM call was considerably larger than the corresponding REST call, but there were far fewer of them and total network traffic was smaller for CSOM. Also, for the REST calls, over 80% of the traffic was in HTTP Headers, not the actual call data we were sending over the wire.
Testability listed highly in my estimation because its something I think SharePoint developers are sorely behind the curve with and so its an important factor for us to consider. In the session demo, I used Telerik’s JustMock product, but you could likely use any suitable mocking product. In the end, each API was sufficiently testable for most situations.
Intellectual Property Protection is an up-and-coming factor that more developers are starting to pay attention to with the introduction of the App Model and the SharePoint Store for Apps.
Last comes Developer Concerns – not because they’re not important, but because they are, unfortunately, the least important factor in our decision. Too often, though, because it’s the developers making the decision, it is these factors which drive things. I think that’s wrong. Again, these are important, but they’re not more important than the other factors, and often they are largely a matter of opinion or preference.
One final point I make in the session and post is that you don’t need to make an either-or decision on your API choice. They can co-exist nicely if that’s what is appropriate for your situation. You can use REST for one part of the application and CSOM for another without any problem.
Overall, there is no bad decision here, provided that you actually make a conscious decision based upon each particular situation.
The source code I used for all of the demos in the session is available at the end of the post.
Again, the full session write up is available here: http://blog.mannsoftware.com/?p=1521
DaveTags Apps, CSOM, REST, SharePoint 2013