Client-Side Object Model in SharePoint 2013

Client-Side Object Model in SharePoint 2013

The client-side object model (CSOM) provides client-side applications with access to a subset of the SharePoint Foundation server object model, including core objects such as site collections, sites, lists, and list items. As described in Data Access for Client Applications, the CSOM actually consists of three distinct APIs—the ECMAScript object model, the Silverlight client object model, and the .NET managed client object model—that target distinct client platforms. The ECMAScript object model and the Silverlight client object model provide a smaller subset of functionality. This is designed to enhance the user experience, because it minimize the time it takes Silverlight applications or JavaScript functions running in a Web page to load the files required for operation. The .NET managed client object model provides a larger subset of functionality for standalone client applications. However, these APIs provide a broadly similar developer experience and work in a similar way.

              Of the three principal approaches to client-side data access, using the CSOM APIs is the only approach that provides the kind of hierarchical, strongly-typed representation of SharePoint objects, such as sites and Webs, that compares to server-side development. The CSOM is the only approach for any client-side data access scenarios beyond list queries. The CSOM allows you to query SharePoint lists by creating CAML queries. This is the most efficient way to query lists, although it requires that developers revert to creating CAML queries. Specific cases where you should favor the use of the CSOM include the following:



Client-Side Object Model Fundamentals:

The managed and JavaScript client object model are maintained in separate libraries, which are located under a SharePoint system directory. The managed client object model is contained in the assemblies Microsoft.SharePoint.ClientRuntime.dll, which can be found in the ISAPI folder. The JavaScript client object model is contained in the library sp.js, which is located in the LATOUTS folder. Each of these models have different programming interfaces which interact with SharePoint through WCF service named client.svc as shown in below figure.

Working with the Managed Client Object Model:

To start the development in the managed client object model, you will need to add references of Microsoft.SharePoint.Client.dll, Microsoft.SharePoint.ClientRuntime.dll into the assemblies and add the using statement for Microsoft.SharePoint.Client namespace and start writing code.


Working with the JavaScript Client Object Model:

The primary purpose of JavaScript client side object model is to talk with SharePoint without requiring a full-page post back. To access the JS CSOM the calling page must reference the following two files:
SP.Runtime.js
SP.js
Each of these are located in the _layouts/15/ directory under each SharePoint site; for example, http://myserver/sitename/_layouts/15/SP.js.



Pros

• Ideal for accessing cross farm data when Search API is not an option or real-time remote data access is required.
• Allows submitting CAML queries directly from client side logic, making it fastest client side data access option.
• Supports Async processing, Request Throttling, and Batch object handling
• CSOM can query external list data within a site
• Supports Site Collection level SharePoint Object Model. It doesn’t provide administrative objects or objects that are scoped higher than site collection.
• No IISREST is required while deploying a Silverlight or JavaScript CSOM based implementation. E.g. JavaScript CSOM can be implemented with just a Content Editor Web part.

Cons

• Can’t access data outside of current site collection
• Query Throttling override is not supported
• Since these are web services interface, can’t accessed from Sandbox Solutions
• Requires learning of CAML to query small result set – Hard coded, Un complied, Not strongly typed CAML query
• Can’t elevate the user privilege using RunWithElevatedPrivilege or Impersonate using CSOM. It means, results retrieved using CSOM are always security trimmed by default.
• Requires IISREST while deploying farm level, .NET managed CSOM code on the server

SharePoint 2013 REST service

SharePoint 2013 introduces a Representational State Transfer (REST) service that is comparable to the existing SharePoint client object models. Now, developers can interact remotely with SharePoint data by using any technology that supports REST web requests. This means that developers can perform Create, Read, Update, and Delete (CRUD) operations from their apps for SharePoint, solutions, and client applications, using REST web technologies and standard Open Data Protocol (OData) syntax.


How the SharePoint 2013 REST service works

SharePoint 2013 adds the ability for you to remotely interact with SharePoint sites by using REST. Now, you can interact directly with SharePoint objects by using any technology that supports standard REST capabilities. To access SharePoint resources using REST, construct a RESTful HTTP request, using the Open Data Protocol (OData) standard, which corresponds to the desired client object model API. 

For example:

Client object model method:

List.GetByTitle (listname)

REST endpoint:

http://server/site/_api/lists/getbytitle ('listname')

The client.svc web service in SharePoint handles the HTTP request, and serves the appropriate response in either Atom or JSON (JavaScript Object Notation) format. Your client application must then parse that response. The figure below shows a high-level view of the SharePoint REST architecture.

Because of the functionality and ease of use that client object models provide, they remain the primary development option for communicating with SharePoint sites by using .NET Framework managed code, Silverlight, or JavaScript.
REST Based API – WCF Data Services

Major Features

• New in SharePoint 2010
• Implemented as REST based WCF Data Services – ListData.svc, REST is HTTP-based XML data transfer design pattern based on OData protocol – Stateless, cacheable, uniform, Able to maintain & browse lists using HTTP verbs – GET, POST, PUT, DELETE, and MERGE
• Returns results in ATOM Feed or JSON format (For JavaScript clients)
• Available for Lists (ListData.svc) and Excel Services REST API (ExcelRest.aspx)
• Add Service Reference to ListData.svc, Proxy class provides LINQ-based strongly-typed access.

Pros

• Confronts Open Data (OData) protocol to support batching, concurrency, and partial updates
• Client-side technique with strongly typed access, Intelligence Support, LINQ style productivity, and compile time errors checking against from proxy class
• Can be used in Silverlight as a replacement for Client OM for strongly typed access
• Can be query from any kind of client: Silverlight, JavaScript, and even from PHP and JAVA.

Cons

• Supported only for Lists and Excel Services
• Needs to refresh the proxy class if List Schema changes
• Since these are web services interface, can’t accessed from Sandbox Solutions
• Overhead of three Query conversations from URL based REST Queries to LINQ Queries to CAML Queries
• Can be used against only SPList, can’t used against SPWeb, SPSite, or SPUser, doesn’t support SharePoint Object Model
• Can’t query external list data within a site
• Can’t query more than 1000 items at a time

CSOM vs SPService 


SPServices


 Pros:

• A wide range of SharePoint functionality is exposed with the ⦁ SOAP Web Services, much of which is not available in CSOM
• Allows anonymous access (assuming it is enabled for the underlying objects).
• Works cross-site and cross-domain, assuming that the authentication model you are using allows it.
• Simpler syntax than the CSOM. Simply pass the required parameters to the Web Service operation, e.g., GetListItems
• Built on top of jQuery, which is very good at ensuring cross-browser compatibility.
• Regularly updated and refined to be compatible with new versions of jQuery and to add new functionality based on user input
• Works identically in SharePoint 2007 and 2010 (where the same Web Services exist – see ⦁ chart)

Cons

• The SOAP Web Services which SPServices wraps is “old” technology which only returns XML.
• Because the SOAP Web Services are older technology, they may not be supported as long as CSOM

CSOM


Pros

• Provides access to the “modern” RESTFul Web Services which return JSON or XML based upon your need
• Coding patterns mirror .NET, which may make more sense to .NET developers.

 Cons

• No anonymous access.
• No cross-site or cross-domain capabilities.
• Complicated syntax which mirrors .NET coding patterns, which may make less sense to Web developers.
• Have to create your own success and failure methods.