SharePoint Apps Playbook Series: Part 5 – Client Side API: REST vs JSOM

As a SharePoint Developer since SharePoint 2003, I have lived in the APIs that were available from the good old days of RPC, to ASMX Web Services, to Server Side API (Managed APIs (.NET) – Microsoft.SharePoint.dll), to the Client Side API. I often get asked “what is the best Client Side API to use with HTML/JavaScript App Model approach…JSOM or REST?”. When I first started answering this I was extremely bias as the JavaScript Object Model (JSOM) API is very similar to the .NET Object Model API.

Us developers tend to stay with what is familiar to us, but as I started to learn AngularJS I noticed that a more standardized approach to calling Platform APIs was to use OData. There is some confusion between the use of the term “REST” and “OData” in the way Microsoft explain this REST API, I found a great explanation from Bizcoder here.

Laying this out in a blog post is tough, I sketched this out in OneNote as  a table and am going to attempt this here in this post.


Standard RESTful Urls Have to use CAML (sigh)


Chatty – Although can use join commands to do less fetches. Heavier payload, but built in paging support. 

REST is significantly smaller return size. But requires more calls and is therefore large return size.

Batch calls. 

Size of return is smaller than REST.

Return type

Native JSON object Untyped complex object


Easier to learn if you already know REST Easier to learn if you already know SharePoint Managed APIs. Lots more community samples.


Can test with URLs directly in browser and Fiddler can inspect JSOM return Fiddler can inspect returned objects but complex objects hard to read easily


Less SharePoint REST API documentation right now Much more SharePoint JSOM API documentation available


Missing some APIs available in JSOM 

Still some APIs missing that are available in Managed APIs

Still some APIs missing that are available in Managed APIs


Easily plugs into Frameworks like knockout, angularjs, jQuery etc. Very hard to plug into

There are some great SharePoint developer community bloggers who have also written about this such as Andrew Connnell, Brian Farnhill. Also Rob Windsor and Sahil Malik did a great PluralSight course on REST/JSOM. David Mann also has a great session on this from the SharePoint Conference 2014 who also has a PluralSight course too on this. There are lots of good articles introducing REST and JSOM available on TechNet also.

Have other opinions…would love to hear them…

7 thoughts on “SharePoint Apps Playbook Series: Part 5 – Client Side API: REST vs JSOM”

  1. Personally this comes down to, the right tool for the job. Speed is a key factor here, if it can be done in rest quickly then it should be done in REST. It’s much more lightweight, and its structure lends to simple user experience design by segmenting the deferred calls in an intelligent way. Taking this to point using REST with deferreds can give a massive performance increase to your application, and I feel with correct implementation this should be the go to for most operations. However there are certain elements that aren’t available like SPBasePermissions, which just last week I had to use JSOM for. Not a big deal, its good, albeit little more complex to deal with. Also if you find that it’s remembering the endpoints grab a copy of these: they are golden. Great part of the series, thank you Jeremy!

  2. Great post Jeremy.
    Understanding the REST vs JSOM differences is very difficult. There is little documentation on the REST side. A great tool to use is the SPRemoteAPIExplorer Visual Studio Extension.

    1. I’ll keep coming back and adding to this for sure.
      I had totally forgotten about that add on for Visual Studio. It’s really neat to be able to see the return types of the APIs!

  3. RE Coverage: I don’t think its fair to say “Missing some APIs available in JSOM”. JSOM simply formats a request to the ProcessQuery endpoint via HTTP, which can easily be done just like a HTTP REST call. CSOM and JSOM simply provides lazy people with a nice wrapper around the TypeId calls, which can be easily formatted and submitted and is supported.

    In terms of the “Still some APIs missing that are available in Managed APIs”, this statement will be true for all of time. For obvious reasons, there is no way to achieve parity between server and client OMs.

    Also, the ultimate documentation of the REST apis (used by the MSDN doc team) is the sprest tool (

    1. Thanks Chris, yep, I’ll have more details on what’s different between the two once I’m on board and will disclose. Both JSOM and CSOM are generated by the same source, I just need to confirm exactly as there appears to be somethings that aren’t there.
      How many hits are you getting on the SPRest tool? I can only see 3 votes so far 🙁 It’s a shame, that and UserVoice are underused.

Leave a Reply