List Items manipulation via REST API in SharePoint 2010

Introduction

Apart from CSOM API,  REST API introduces another approach to access SharePoint list data from platforms on which the CSOM may be unavailable. The SharePoint REST interface is based on the REST-based Open Data protocol (OData) which  is a platform-independent open standard.

Examples

This section contains sample code for all of the CRUD operations.

Create

In order to  perform a Create operation via REST, you must perform the following actions:

  • Create an HTTP request using the POST verb.
  • Use the service URL of the list to which you want to add an entity as the target for the POST.
  • Set the content type to application/json.
  • Serialize the JSON objects that represent your new list items as a string, and add this value to the request body.

The following code snippet demonstrates how to perform a Create operation against a SharePoint list.

Read

In order to  perform a Read operation via REST, you must perform the following actions:

  • Create an HTTP request using the GET verb.
  • Use the service URL of the list item to which you want to add an entity as the target for the GET.
  • Set the content type to application/json.

The code sample demonstrates of how to retrieve an item based on its ID:

Update

To  update an existing entity, you must perform the following actions:

  • Create an HTTP request using the POST verb.
  • Add an X-HTTP-Method header with a value of MERGE.
  • Use the service URL of the list item you want to update as the target for the POST
  • Add an If-Match header with a value of the entity’s original ETag.

In contrast to reading list item  to update an item you will need to pass the eTag value, which could be obtained during item read.

About eTags

When updating or deleting items within SharePoint lists via REST you must specify the Entity Tag (eTag) value that was returned with the item during the initial query. This enables SharePoint to determine if the item has changed since it was requested. Alternatively you can tell SharePoint to perform the operation regardless by specifying * as the eTag value. For example:

  1. “If-Match”: item.__metadata.etag can be used to specify the actual eTag value (‘item’ is the object returned from SharePoint containing the list item in JSON format).
  2. “If-Match”: “*” can be used to match any eTag value resulting in the operation being performed regardless of the actual value.

They form part of the Ajax call for updating an item. eTags are part of the HTTP Protocol V1.1, more information on the topic can be found here.

Delete

To  delete an  entity, you must perform the following actions:

  • Create an HTTP request using the POST verb.
  • Add an X-HTTP-Method header with a value of DELETE.
  • Use the service URL of the list item you want to update as the target for the POST
  • Add an If-Match header with a value of the entity’s original ETag.

The Delete operation is similar to Update operation,  the code below demonstrates how to perform a Delete operation:

References

Introduction to Client Forms Validation in SharePoint 2013

Client side event handlers in SharePoint

In addition to server side Event Model,  SharePoint also provides client side  event handling capabilities when working with List Forms.

Let’s see briefly how it works. In List Forms pages Save button click handler triggers PreSaveItem function , PreSaveItem function is declared in forms.js:

PreSaveAction function from another hand, is a user defined function that allows to override standard behavior for a Save button handler, so in terms of server side event model it is a binding mechanism.

I find this mechanism  pretty convenient for implementing custom client side validation in List Forms,  the following example demonstrates how to implement client side validation for Email field in Contacts list:

EmailValidate

Client forms validation in SharePoint 2013

In SharePoint 2013 as part of  Client-Side Rendering (CSR), there is SPClientForms.ClientValidation  namespace (clientforms.js) that contains  types and objects for performing  client side validation in List Forms. For example,

SPClientForms.ClientValidation.RequiredValidator object is intended for evaluating the value of an field control to ensure that the user enters a value (it  is invoked for a fields when SPField.Required property is set to True):

Below is provided a complete example that demonstrates how to implement  client-side validation for Email field in Contacts list:

Key points:

  • CustomClientValidation.EmailValidator object implements a custom validation  for Email field
  • since Email field is a standard Text Field,  the rendering of field control is reused, only custom validator is registered for a field (see function EmailField_Edit for a details)