close

The REST APIs and OData in SharePoint 2013

Posted by Errin O'Connor on May, 12, 2015 09:05

REST APIs in SharePoint 2013 are now compatible with OData, the industry standard for creating and consuming data APIs. The official reference for OData, as well as to track updates regarding this industry standard, can be found at the following link: http://www.odata.org

OData’s official description, in essence, states that OData builds on core protocols like HTTP and commonly accepted methodologies like REST, resulting in a uniform way to expose full-featured data APIs.

In terms of SharePoint 2013, OData is a protocol for interacting with RESTful web services. It was released under Microsoft’s open specification promise; it works on top of standard HTTP using HTTP GET, POST, PUT, and DELETE verbs and returns standard ATOM or JSON formatted results.

For more information regarding Microsoft’s open specifications promise, refer to the following link:

https://docs.microsoft.com/en-us/openspecs/dev_center/ms-devcentlp/51a0d3ff-9f77-464c-b83f-2de08ed28134

RESTful web services are basically those services or applications that conform to REST constraints, and any service that does not conform to the required constraints should not be considered RESTful.

There is a very strong focus on resources within RESTful web services and they should be simple for a developer to utilize. These services should follow these four principles:

  • Utilize HTTP methods appropriately
  • Expose data in a directory structure
  • Be stateless
  • Transfer either XML or JSON formatted results, as shown in the images below

Microsoft has also recently released a 300-plus page OData/open specifications whitepaper for protocols, file formats, languages, and standards, as well as overviews of the interaction among each of these technologies, which can be accessed at the following link:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-odata/2b686a1a-9e1f-456f-80ff-072a010fc278

REST and Search in SharePoint 2013

The new Search capabilities in SharePoint 2013 include a Search REST service that you can utilize to add search features and functionality to your organization’s client applications as well as your mobile applications that support REST web requests.

This capability enables you to use the Search REST service to submit Keyword Query Language (KQL) or FAST Query Language (FQL) queries in apps for SharePoint, mobile apps, and remote client apps. In addition, the new Search REST service also supports both HTTP POST and HTTP GET requests.

For GET requests, you would construct the URI for query GET requests to utilize the Search REST service by using the following:

/_api/search/query

The GET request specifies the query parameters in the URL and can utilize two options for constructing GET requests as detailed here:

http://server/_api/search/query?query_parameter=value&query_parameter=value

or

http://server/_api/search/query(query_parameter=value&query_parameter=<value>)

For POST requests, you would construct the URI for query POST requests to utilize the

Search REST service by using the following:

/_api/search/postquery

The POST requests are passed via the query parameters in the request in JSON format, and the HTTP POST version of the Search REST service supports all the parameters supported by the HTTP GET version.

You should utilize POST requests whenever the following is true:

  • You have concerns about the length of your URL due to URL length restrictions that may be experienced with a GET request.
  • You cannot specify the query parameters via a simple URL such as those in pass parameter values that contain a complex type array because there is added flexibility around the construction of POST requests.

You must ensure that whenever a call is made to the Search REST service, the specific query parameters are included with the request because these query parameters are used to construct the underlying SharePoint search query.

These query parameters are specified in different manners between GET and POST requests:

  • GET requests specify the query parameters in the URL.
  • POST requests pass the query parameters in the body in JavaScript JSON format.

EPC Group’s Nationally Recognized Practice Areas

EPC Group leading Custom Application DevelopmentSharePointOffice 365, Infrastructure Design and Business Intelligence Practice areas continue to lead the way in providing our clients with the most up-to-date and relevant information that is tailored to their individual business and functional needs.

Additional “From the Consulting Trenches” strategies and methodologies are covered in EPC Group’s new book, “SharePoint 2013 Field Guide: Advice from the Consulting Trenches” covering not only SharePoint 2013, Office 365 and SharePoint Online but Information Management, ECM\RM and overall compliance strategies in this ever changing world of “Hybrid IT.”

Errin O'Connor
About the Author

Errin O'Connor

With over 25 years of experience in Information Technology and Management Consulting, Errin O’Connor has led hundreds of large-scale enterprise implementations from Business Intelligence, Power BI, Office 365, SharePoint, Exchange, IT Security, Azure and Hybrid Cloud efforts for over 165 Fortune 500 companies.

Let's Get to Work Together!

Talk to our Microsoft Gold Certified Consultants

Contact EPC Group

Call for help:

(888) 381-9725

Email Us:

[email protected]

Head Office:

4900 Woodway Drive - Suite 830 Houston, Texas 77056