Introduction
SharePoint 2013 introduces a Representational State Transfer (REST) service that is comparable to the existing SharePoint client object models. REST allows for a minimum data to be passed using the same well-established mechanism that defines the web without a lot of the encumbrances introduced by fatter protocols. It allows programmers to build programs easily that access and act upon data exposed via APIs, even in environments with unreliable network speeds and limited computing power. REST works almost exactly like a website in a browser. A resource is exposed to a program via a URL. This means the developers can perform Create, Read, Update, and Delete (CRUD) operations from their SharePoint Add-ins, solutions, and client applications, using REST web technologies and standard Open Data Protocol (ODATA) syntax. ODATA standard defines a set of best practices for building and consuming RESTful APIs.
In REST, everything is a ‘RESOURCE’ like it can be pictures, video files, Web pages, business information, or anything that can be represented in a computer-based system. The purpose of a service is to provide a window to its clients so that they can access these resources. Separate from their representations-resource may represent as per as request content type either JSON or XML etc.
Some of the amazing features of web are:
-It’s a 40 years old matured and widely accepted HTTP protocol.
-HTTP protocol is stateless.
-The URI (Uniform Resource Identifier):-By, which we can go and locate any resource on the web.
What is REST API and its Constraints?
A RESTful API is an application program interface (API) that uses HTTP requests to Retrieve (GET), Update (PUT), Create (POST) and Delete (DELETE) data. Representational state transfer (REST), which is used by browsers, can be thought of as the language of the Internet. Generally, we use more GET and POST method request to do any operations. But, who are unable to make direct PUT or DELETE calls need to pass in their requests through the Request Header “X-HTTP-Method-Override”.
There are six constraints in REST as follows:
1) Client-Server
2) Stateless
3) Cacheable
4) Uniform Interface
5) Layered System
6) Code-On-Demand
Overview of the Six Constraints:
Client-Server
The uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface is not altered.
The client sends the ‘Request’ to the server and the server revert backs the ‘Response’ to the Client as displayed in the below.
REST
Stateless
One client can send multiple requests to the server; however, each of them must be independent, that is, every request must contain all the necessary information so that the server can understand it and process it accordingly. In this case, the server must not hold any information about the client state. Any information status must stay on client – such as sessions.
Cacheable
Because many clients access the same server, and often requesting the same resources, it is necessary that these responses might be cached, avoiding unnecessary processing and significantly increasing performance.
Uniform Interface
The uniform interface constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently. It means,
- HTTP Verbs (GET,POST,PUT,DELETE)
- URIs (resource name)
- HTTP response (status and body)
Layered System
A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies.
Code-On-Demand (Optional)
This condition allows the customer to run some code on demand, that is, extend part of server logic to the client, either through an applet or scripts. Thus, different customers may behave in specific ways even using exactly the same services provided by the server. As this item is not part of the architecture itself, it is considered optional. It can be used when performing some of the client-side service which is more efficient or faster.
Sharepoint REST Services Architecture
SharePoint data and objects can be accessed using any technology that supports REST web requests like the ones shown in the picture below. This ability of SharePoint 2013 opens the boundaries of integration and collaboration with other REST based platforms and devices.
As the REST service architecture in the preceding figure shows, a HTTP request using the OData protocol is sent to SharePoint and your application will receive the response in JSON or ATOM format that your client application needs to parse and utilize.
The HTTP request is handled by the “client.svc” web service in SharePoint 2013. The “client.svc” web service internally calls the server object model that retrieves data from the SharePoint content database as shown below. SharePoint Apps are built using these architectural concepts.
REST Syntax URIs
While constructing REST URIs, follows the below general syntax. Http protocal with tagging server name of the sharepoint site application. In sharepoint 2010, using ‘ListData.svc’ service to get the sharepoint list items. Further, the ‘Client.svc’ service been introduced, to get the List data and oData (Open Data Protocal) operation. The ‘client.svc’ used to tag in sharepoint like “http://ServerName/_vti_bin/client.svc/” then started to constuct the URIs as “http://ServerName/_api/’. The “_api” is a friendly name, since it is easier to read.
General Syntax
Example:
Conclusion
REST is more simple and easy to use. It uses HTTP protocol for producing or consuming web services and is lightweight as compared to others, supports different format like text, JSON and XML, web services call can be cached to improve performance. The web services http methods like GET, PUT, POST and DELETE can be used to perform CRUD operations.
