8-Week Microsoft Teams AppDev Accelerator Program
Limited seats available! - Start date: Wednesday, April 16, 2025
Join Today & Save $1,000
articles

Why the SharePoint REST API is Better than SharePoint's CSOM

As a SharePoint developer, I explain why I prefer REST API over CSOM despite its downsides. Learn about its advantages & access a wide range of samples.

Why the SharePoint REST API is Better than SharePoint's CSOM
by Andrew Connell

Last updated October 22, 2013
3 minutes read

Share this

Focus Mode

  • Feedback & questions

A few months ago I wrote how I prefer using the REST API in SHAREPOINT over using the CSOM. Sure there are some downsides to this (no coverage for workflow or taxonomy, no batching just to name a few). However the advantages outweigh the downsides (3rd part libraries and frameworks mostly work with REST, more standards, more samples because it isn’t SharePoint specific, etc).

One complaint I get from people is from the fact you have a bit more code to write for each call. Sure… you have to build the request each time, but that’s just an opportunity for reuse.

I’ve created two libraries I use for all my SharePoint REST calls that really cut down on constantly rewriting the same thing over and over. At the same time, this makes it a lot more readable.

The first one is used to get the SharePoint specific URLs:

The second one is for generating the calls for reads & writes. As you can see, different methods are used for different tasks:

And now, when I want to get data, the call is quite clean (the following examples are from my SharePoint 2013 App, a SharePoint Hosted App implemented as a Single Page Application (SPA)):

// get all learning paths
var query = spAppUtils.getAppODataApiUrl()
+ "/web/lists/getbytitle('Learning Paths')/Items"
+ "?$select=Id,Title,Published,Keywords1,OData__Comments"
+ "&$filter=Published eq '" + ((published) ? 1 : 0) + "'"
+ "&$orderby=Title";

// execute query
return $.ajax(oDataUtils.getRequest(query))
.then(onSuccess)
.fail(onGetLearningPathFail);

As are creates…

//create new object
var payload = buildJsonLearningItemPayload(learningItem);
endpoint = spAppUtils.getAppODataApiUrl()
+ "/web/lists/getbytitle('Learning Items')/Items";
requestData = oDataUtils.newItemRequest(endpoint, payload);

// add handlers
requestData.success = function (response) { deferred.resolve(response); };
requestData.error = function (error) { deferred.reject(error); };

// submit query
$.ajax(requestData);

and updates…

//update existing object
var payload = buildJsonLearningItemPayload(learningItem)
endpoint = learningItem._permalink();
requestData = oDataUtils.updateItemRequest(endpoint, payload, learningItem._etag());

// add handlers
requestData.success = function (response) { deferred.resolve(response); };
requestData.error = function (error) { deferred.reject(error); };

// submit query
$.ajax(requestData);

Or deletes…

//delete existing object
var endpoint = learningItem._permalink();
var requestData = oDataUtils.deleteItemRequest(endpoint);

// add handlers
requestData.success = function (response) { deferred.resolve(response); };
requestData.error = function (error) { deferred.reject(error); };

// submit query
$.ajax(requestData);

In the samples above, I use the same method for creating the object I’m going to send to the rest services in the create-update-delete operations:

/* Create a JSON object to post to the learning item */
function buildJsonLearningItemPayload(learningItem) {
  var payload = {
    __metadata: { "type": "SP.Data.LearningItemsListItem" },
    Title: learningItem.Title(),
    OData__Comments: learningItem.Description(),
    URL: {Url: learningItem.URL(),
    Description: learningItem.URL()},
    ItemType: learningItem.ItemType(),
    LearningPathId: learningItem.AssociatedLearningPath().Id()
    };

  return JSON.stringify(payload);
};

Cool huh? In reality I combine these two in my SharePoint projects. I broke them up here for readability. If I’m not working in SharePoint, I don’t need the stuff in the first script.

Andrew Connell, Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.
author
Andrew Connell

Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.

Andrew Connell is a full stack developer who focuses on Microsoft Azure & Microsoft 365. He’s a 20+ year recipient of Microsoft’s MVP award and has helped thousands of developers through the various courses he’s authored & taught. Whether it’s an introduction to the entire ecosystem, or a deep dive into a specific software, his resources, tools, and support help web developers become experts in the Microsoft 365 ecosystem, so they can become irreplaceable in their organization.

Feedback & Questions

newsletter

Join 10,000+ developers for news & insights

No clickbait · 100% free · Unsubscribe anytime.

Subscribe to Andrew's newsletter for insights & stay on top of the latest news in the Microsoft 365 Space!
blurry dot in brand primary color
found this article helpful?

You'll love these!

Microsoft Deprecates User Code Part of Sandboxed Solutions

Microsoft Deprecates User Code Part of Sandboxed Solutions

September 10, 2013

Read now

Microsoft Deprecates User Code Part of Sandboxed Solutions

Microsoft Deprecates User Code Part of Sandboxed Solutions

September 10, 2013

Read now

SharePoint 2013: CSOM vs. REST ... My Preference and Why

SharePoint 2013: CSOM vs. REST ... My Preference and Why

June 29, 2013

Read now

bi-weekly newsletter

Join 10,000+ Microsoft 365 full-stack web developers for news, insights & resources. 100% free.

Subscribe to Andrew's newsletter for insights & stay on top of the latest news in the Microsoft 365 ecosystem!

No clickbait · 100% free · Unsubscribe anytime.

Subscribe to Andrew's newsletter for insights & stay on top of the latest news in the Microsoft 365 Space!