CSOM, JSOM and REST API in SharePoint : Quick Overview

CSOM, JSOM, and the REST API all interact with SharePoint data from outside server-side code — the real question is which one fits a given project, not which one is “best.” Here’s what each actually is, working code for all three doing the same operation, and how they compare.

In this post: What each one actually is · The same operation in all three · Comparison · Best practices · REST API vs. Graph API · When would you actually use this? · Related reading

What each one actually is

CSOM (Client-Side Object Model): a .NET-based API for console apps, Windows apps, and PowerShell — the default choice for migration tools, provisioning scripts, and admin automation written in C#.
JSOM (JavaScript Object Model): the JavaScript equivalent of CSOM, running in the browser — historically used in Script Editor Web Parts and classic-page customizations. Requires SharePoint’s own script libraries (SP.js) loaded first, typically via SP.SOD.executeFunc, before any JSOM call will work — a common source of “undefined is not a function” errors for anyone new to it.
REST API: plain HTTP, callable from any language that can make a web request — the default for SPFx, mobile apps, and third-party integrations.

In SharePoint Online specifically, full-trust server-side code isn’t an option at all — these three (plus Graph, covered below) are the actual toolset, not a stylistic preference.

The same operation in all three

Getting a list’s title, three ways:

CSOM (C#):

using Microsoft.SharePoint.Client;

ClientContext context = new ClientContext("https://contoso.sharepoint.com/sites/demo");
List list = context.Web.Lists.GetByTitle("Documents");
context.Load(list);
context.ExecuteQuery();

Console.WriteLine("List Title: " + list.Title);

JSOM (JavaScript):

var ctx = SP.ClientContext.get_current();
var list = ctx.get_web().get_lists().getByTitle("Documents");
ctx.load(list);

ctx.executeQueryAsync(function () {
    console.log("List Title: " + list.get_title());
}, function (sender, args) {
    console.error('Error: ' + args.get_message());
});

REST API (JavaScript with fetch):

fetch("https://contoso.sharepoint.com/sites/demo/_api/web/lists/getbytitle('Documents')", {
    method: "GET",
    headers: {
        "Accept": "application/json;odata=verbose"
    }
})
.then(response => response.json())
.then(data => console.log("List Title: " + data.d.Title))
.catch(error => console.error("Error:", error));

Comparison

Feature	CSOM	JSOM	REST API
Language	C# / .NET	JavaScript	Any (HTTP)
Best for	.NET admin/migration tooling	Legacy classic-page customization	SPFx, integrations, mobile
Active in new development	Yes	Rarely — legacy only	Yes
Batch support	Yes	Yes	Yes, via `$batch`
Cross-platform	Windows-oriented	Yes (runs in-browser)	Yes
Error handling	Structured exceptions	Callback-based	Standard try/catch on the HTTP call

If you’re starting a new project in SharePoint Online, REST is almost always the right default — JSOM is legacy-maintenance territory at this point, not a starting choice.

Best practices

Default to REST for new SPFx work and integrations — it’s the most broadly compatible and best-documented of the three today.
Reach for CSOM specifically for .NET/PowerShell admin and migration tooling, where it’s still the natural fit.
Avoid starting anything new in JSOM — use it only when maintaining an existing classic-page customization already built on it.
Load only the fields you need in CSOM/JSOM queries (explicit Load/load calls), and use $select/$expand in REST — all three let you over-fetch by default if you’re not deliberate about it.
Batch requests where the operation touches more than a handful of items, to cut down round-trips.

REST API vs. Graph API

Worth distinguishing from the three above: SharePoint’s REST API is SharePoint-specific. Microsoft Graph is the broader Microsoft 365 API covering SharePoint alongside Teams, Outlook, and OneDrive from one unified endpoint and auth model. Same operation, both ways:

SharePoint REST: https://contoso.sharepoint.com/sites/demo/_api/web/lists/getbytitle('Tasks')
Graph: https://graph.microsoft.com/v1.0/sites/contoso.sharepoint.com:/sites/demo:/lists/Tasks

SharePoint REST is the better fit for SharePoint-only CRUD; Graph earns its extra setup when the same integration also needs to touch other Microsoft 365 services under one auth model.

When would you actually use this?

A migration tool needs to move documents with metadata between environments — CSOM in a .NET console app or PowerShell script.
You’re maintaining a Script Editor Web Part on a classic page and need to touch existing JSOM code — not the place to introduce a new dependency, just work within what’s there.
You’re building an SPFx web part or a mobile/third-party integration — REST API (or Graph, if it spans multiple M365 services) by default.

References: SharePoint .NET CSOM, SharePoint JSOM, SharePoint REST API, Microsoft Graph Explorer.

How to Send an HTTP Request in SharePoint via JavaScript — the REST option from this post, in more depth (digest tokens, headers, a real POST example).
Exploring SharePoint REST API Endpoints — a reference list of endpoints once you’ve settled on REST.

That’s the full picture across all three (plus Graph). Questions about which fits your project? Comment below.