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
I’m happy to announce that I’ll be speaking at the SharePoint Conference in March. My session is Deep Dive: REST and CSOM Comparison, which fits in nicely with the Pluralsight course I made that just went live (and it’s successive parts coming in Q1).
Details available here: http://www.sharepointconference.com/content/sessions/SPC423
I’ll post more information here as the conference gets closer. See you in Vegas!
This is actually the first of three parts to the course, with the next two parts coming in Q1 2014. Here's the table of contents for part 1:
- Fiddler and an Introduction to REST
- Reading SharePoint Data with REST APIs
- Creating, Updating and Deleting SharePoint Data with REST APIs
- Final Thoughts for Part 1
I'm obviously a bit biased, but I think there's a LOT of good material in here – including some that I don't think you can find anywhere else, or that other published content is just plain wrong or incomplete. It intentionally starts out very basic but then quickly moves into the deep end of the pool, covering both REST and JSOM. There are also modules on the best/proper ways to work with libraries (both deploying to SharePoint and downloading to the user's browser) and finishes with a discussion on the REST vs. CSOM debate and which one you should use.
Stay tuned for more highlights on the content. If you don't have a Pluralsight subscription, you can get one for $29/month, or wait for the companion e-Book (more on that later!)
*: I say "real" because there is a course I recorded for Critical Path Training originally that was converted to a PS course but I don't really count that one