SharePoint 2013 : How to develop Custom Search Apps Using REST API

In this article we are going to deal with Search Scenarios using enhanced REST API in SharePoint 2013. To make the story more interesting I am going to make use of new App Model offered by SharePoint 2013. Here we will be going to explore SharePoint Hosted App which is one of the three types of Apps offered under SharePoint 2013 App Model. In this article we will cover a simple scenario where we will create a Custom Search (SharePoint Hosted) App based on SharePoint 2013 Search and REST API provided by SharePoint 2013, that will perform search on Crawl Data aggregated by the Search Crawler.


  1. App Development Environment must be configured properly.
  2. SharePoint 2013 Search Service Application must be created and configured.
  3. Sample Data Sources must be created with in the Scope targeted by the crawler.
  4. Full Crawl must be finished.
  5. Fiddler Web Proxy should be installed. You can get Fiddler from

Following are the steps involved in the development of Custom Search App using REST API:

Step-1 : Start Visual Studio 2012/2013 and Select “App for SharePoint 2013” project template as shown below


Step-2 : Modify the Default.aspx Page and add the UI Elements for Search App. For the sake of simplicity I am using basic HTML for the presentation but we can design the UI as compelling as it needs to be by making use of enhanced UI support from HTML5 & CSS3.


Step-3: Next thing is to hook up the “Click” event of the button “btnExecuteSearchREST” with an event handler function as shown below:


Step-4:   Now lets’ do the step wise analysis of the actual plumbing


  1. Get the Search Term entered by the user and stored it in the variable “queryText”.
  2. Define Request Headers for the Web Request, Please Note that we mention “odata=verbose” as a part of the value for “Accept” Property, this is a new convention for Web Requests using REST API in SharePoint 2013 and it must be followed else it would produce the following error :


  1. Set “url” property to the URL of the site which is hosting this App using “_spPageContextInfo.webAbsoluteUrl”, you must have to memorize this object as you have to use it on every single page in SharePoint where you want to use the SharePoint Context. This simple object provides you a lot of useful information to work on as shown below


  1. Specify the Search Query using new End Point (_api/search/query/<searchTerm>) provided by SharePoint 2013.
  2. Read the results from the response object and save it to “rows” variable, based on the data structure returned by the response object. We can identify the data structure by analyzing the response object using Fiddler Web Proxy as shown after few steps down the line.
  3. We need to loop through the result set to read the Values based on the Keys returned.
  4. Lastly we need to display the records as required.

Optional: At this point you can make use of some of the JavaScript Frameworks like “Knockout.js” which is based on MVVM Pattern and has an excellent feature of dependency tracking, which allows you to write complex UI logic with much Lesser & Cleaner Code. You can learn Knockout very easily by following the link

Step-5: With this we are all done with the code, now it’s time to build & deploy the App and see it in action. In order to test the Custom Search App, first verify the Data Source which contains the data related to our search term. In our case it is “Customers” List with a Column “ContactTitle” containing the Search Term “Owner” as shown below


Now specify the search term in textbox provided as a part of App UI and click “Execute Search using REST API” as shown below:


Before going to the search result in the “Result Panel” (which is a div on App UI), we should spend a few minutes to analyze the response object to determine what exactly is returning from the server against our request. If we view the response object in Fiddler as shown below, we will see a complete JSON Object containing the data in terms of Key/Value Pairs. This information is very important as this will help us to navigate the result set that we are interested in. Please Note that we utilize this information under Step-4 Point 5, where we are saving the result set from response object to local variable.



Finally if we see to the Result Panel we should be able to get the results based on the search term “Owner”.


This simple demo helps you to grasp the notion of how can we employ REST API while working with Custom Search Apps/Solutions.

Hope this will help someone in need…

SharePoint 2013: How to call OData Web Service End Point Using SharePoint Designer 2013 Workflows

In this article we are going to explore “Call HTTP Web Service” Workflow Action which is newly introduced in SharePoint 2013. In order to test this action will make use of OData Web Service End Point and target the following scenario where Customer Data needs to be auto populated based on the Customer ID using SharePoint Designer Workflow and OData Web Services.


  1. As this is going to be a List Workflow, make sure you must have a Custom List containing three columns “Customer ID”, “Full Name” and “Employer” already created on the site which you are going to select in Step 2 down the line. For the sake of this demo I have created a List with the name “Fill Customer Using Web Service” containing all the required columns.
  2. OData Web Service End Point should be accessible from the system which is running SharePoint Designer.
  3. Fiddler Web Proxy should be installed. You can get Fiddler from

Following are the steps involved in the development of Workflow Calling OData Web Service End Point:

Step-1 : Start SharePoint Designer 2013

Step-2 : Select the site in which you want to create the workflow


Step-3 : Go to left navigation pane and select Workflows


Step-4 : Select List Workflow [From Ribbon] > Select List [In our case it would be “Fill Customer Using Web Service”]


Step-5 : On the Workflow Designer select “Call HTTP Web Service” Action from the Action Ribbon Menu


Step-6 : Create the Workflow variables as shown below


Step-7 : Specify the Web Service End Point, and HTTP Method as shown below


Step-8 : Specify the variable of type Dictionary as placeholder for the incoming response data from the Web Service End Point


Step-9 : Now before proceeding any further lets’ analyze the response from the Web Service End Point. Please note that this step is of high importance and must not be neglected. Fiddler Web Proxy is your best friend when it comes to deal with Web Services. Analysis using Fiddler will provide us with the following Vital Information out of the response

  1. Structure of Data returned as a part of the response
  2. Properties Exposed by the Web Service End Point
  3. Data Types of the Properties
  4. Additional information on Error & Exceptions (If any)


Step-10 : After analyzing the data we come across the fact that we have got the required data in form of Key Value Pairs and the result set can be accessed by using the path “d/PropertyName”. So based on this knowledge we can now set the values for variable “CustomerName” & “CompanyName” using “Get an Item from a Dictionary” Action as shown below.


Step-11 :  As we have got the data from the Web Service End Point and stored in a set of variables, now it is time to update our list using “Set Field in Current Item” Action. We should use two instances of the same Action in order to set the value for both the fields using the variables as shown below


Step-12 : With this we are good to go. Now lets’ Save the Workflow Definition, Check for the Errors and if everything is fine Publish the Workflow.






Step-13 : In order to test the Workflow lets visit our List “Fill Customer Using Web Service” and quickly add a new item. We need to add the Customer ID only and rest of field will be populated by the Workflow


Step-14 : Specify the Customer ID and Save the item.


Step-15 : Start the Workflow on the newly added item.



Step-16 : And sure enough you will get the desired output with “FullName” and “Employer” Columns populated by our workflow using OData Web Service Call.


Though the scenario I mentioned here is quite simple, but this new add-on to SharePoint Designer 2013 is very powerful and could be utilized to cater complex business requirements without using any need of writing modules.

Hope this will help someone in need…