The REST APIs are very straightforward and easy to use and allow for a platform-agnostic development approach. Each query that is submitted is done via a unique URL, and the returned results can be cached by proxy servers. The REST APIs are easier to utilize than a SOAP-based web service and provide for higher productivity when JavaScript and jQuery are used.
You can access resources utilizing REST capabilities in SharePoint 2013 by constructing a RESTful HTTP request, using OData, which corresponds to the desired client object model API.
The client.svc service handles the HTTP request and serves the appropriate response in either Atom or JSON (JavaScript Object Notation) format, and the client application must then parse that response.
EPC Group Tip “From the Trenches”
The endpoints in the SharePoint 2013 REST service correspond to the types and members in the SharePoint client object models. The utilization of these HTTP requests allows for the use of these REST endpoints to perform typical CRUD (create, read, update, and delete) operations against SharePoint entities like SharePoint sites or lists.
The URI (uniform resource identifier) for these REST endpoints closely mimics the API signature of the resource in the SharePoint client object model, as the main entry points for the REST service represent the site collection and site of the specified context that is submitted. To provide an overview of this, a specific site collection can be accessed by using the following:
http:// server / site /_ api / site
If you are wanting to access a specific site, you would do so by using the following:
http:// server / site /_ api / web
The server always represents the name of the server and the site represents the name of the site or the path to the specific site. By using this as a baseline, you can then construct more specific REST URIs by utilizing the object model names of the APIs from the client object model separated by a forward slash (/).
EPC Group Tip “From the Trenches”
The differences between a URI, a URN, and a URL can be confusing due to the similarities
of the concepts of all three of these terms.
- A URI is a uniform resource identifier, which is a string of characters used to identify a name or a resource on the Internet. A URI identifies a resource by location, by name, or both. A URI has two specializations known as URL and URN.
- A URL is a uniform resource locator, which is a subset of the URI. The URL specifies where an identified resource is available, as well as the mechanism for retrieving it, and defines how the resource can be obtained.
- A URN is a uniform resource name is actually a URI that uses the URN scheme but does not imply availability of the identified resource.
This means that both URNs (names) and URLs (locators) are URIs, and a specific URI may be both a name and a locator at the same time.
To clarify this in an example, EPC Group is the consulting firm that I work for and the name “EPC Group” can be used as an “identification.”
There are also a few firms overseas named EPC Group but they are in manufacturing and in other business verticals; so just telling you the company name “EPC Group” does not provide you any specifics on just the face value of the “identification” provided.
Think of the differences, in terms of performing a Bing or Google search, between the terms “EPC Group” and “EPC Group SharePoint 2013 Office 365 Houston.”
The second search term provides additional metadata, which then will provide more specifics to identify the correct company and its location.
A URN is very similar to a name and a URL is similar to a street address; the URN defines the actual identity whereas the URL provides a location. So in summary, a URL is a URI that identifies a specific resource and also provides the means by which you can locate the resource by describing the way to access it.
Note: Some new browser updates, such as in Google Chrome, are now dropping the protocol from the display within the browser, which visually turns URLs into URIs.
Calendar REST API in Office 365 APIs Preview
The Calendar API provides full access to calendar groups, calendars, and events in Exchange Online as part of Office 365. From checking for upcoming events to sending meeting invitations, the Calendar API has it covered.
Mail REST API in Office 365 APIs Preview
The Mail API provides full access to email messages and mail folders in a user’s mailbox in Exchange Online as part of Office 365. From reading to sending email, the Mail API has it covered.
Files REST API in Office 365 APIs Preview
The Files REST API in Office 365 APIs Preview represents a redesign of the file storage and management API for SharePoint. The Files API allows you to access and manipulate the contents of Office documents (files, presentations, spreadsheets, for example), as well as mail, calendar, contacts, and SharePoint data.
EPC Group’s Nationally Recognized Practice Areas
EPC Group leading Custom Application Development, SharePoint, Office 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.”
