Creating New SharePoint Interfaces Using REST
Recently, a friend and colleague, much more savvy in the art of code than I, showed me how to do something that opened a door. I knew it was there, I was aware of the capabilities, but I never really understood the power of REST services until now. Very simply, SharePoint’s REST web services allow you to get SharePoint data from a number of data end-points like lists, libraries, navigation, or the search service. This may seem exceedingly obvious to any SharePoint developer, but for UX guys like me who are more focused on the interface and design, it’s new ground.
What is SharePoint REST?
In this example, I’m using a jQuery AJAX request to access SharePoint’s REST services. Note that this will require the jQuery library to be loaded on the page before the code will work. The most important element of this REST request is the
url parameter. In this case, our request is being made to:
This URL tells SharePoint that we are looking at a list or library called
Pages located at the root of our site domain (
http://yourdomain.com/Pages). To query a different URL or even a subsite, simply change the request URL. In the
success function, we are using
console.log(data) to show the results inside the console of the web browser. Almost every web browser has a console that you can view by turning on developer or inspection tools in the browser settings. After running our script on a SharePoint page, the console looks something like this (screenshot taken in Google Chrome):
While this may look like nonsense, it’s actually real SharePoint data representing the documents located in the Pages library of my SharePoint site. Exploring the console will reveal things like the page title, page content, author, modified or created dates, and more. SharePoint wraps all of this information up inside a JSON object called
d. We can now use this information to do something more useful. Let’s change our script to utilize the
In this example, we’re taking each result returned by SharePoint’s REST services and appending it to the page. This is the true power of SharePoint REST services, in that we can actually create and modify content within the browser window using the information we’ve received from the web services. The result should look something like this, with one result for each page in the library:
Building an entirely new interface
As an example, I created a custom SharePoint list that contains data I will display using REST services. This is simple SharePoint list data, boring and uneventful. The normal SharePoint interface looks something like this:
Using REST, however, we can display this data in any creative format we can imagine. Using the same technique outlined in this post, I have taken this list data and displayed it in a full screen PowerPoint-like format. Users can swipe, touch, click, or key their way from slide to slide, and each slide is enhanced with CSS3 transition effects and HTML5 optimizations. This is the result:
It’s an entirely new interface, and doesn’t even remotely resemble what we know as SharePoint. I’ve added multiple items to the list, and navigating to the next slide shows a completely new layout:
While we started out with a simple example of showing page titles within the SharePoint content area, in this example we’ve built an entirely new interface from the ground up. This is an interface that fills the screen and doesn’t even remotely resemble what we know as SharePoint. Using REST as our source of SharePoint data, the options for customization are nearly limitless.
A short video of this functionality perhaps better demonstrates the final product:
The devil’s advocate
I want to reiterate that I’m not advocating for the abandonment of established techniques like master pages, page layouts, and CSS customization. This is merely another tool in our collective UX and customization toolbox, and should be used accordingly. The aforementioned concerns with search optimization and accessibility are likely the most prominent argument against using these techniques to present your SharePoint information, but that doesn’t mean we can’t utilize them to progressively enhance the experience for our users who can take advantage of the amazing new features of HTML5 and CSS3.
Additionally, I shan’t forget the amazing developers who have known about and have used this technology for years. It’s all new to me, and that has me excited, but in truth I’m merely following in the footsteps of people like Marc Anderson and his SPServices library, which makes great use of SharePoint’s web services and has done so for years. Thanks to Marc and many others, we are perpetually pushing the limits of what we can do with the SharePoint interface.
This article was originally posted on the Protiviti SharePoint Solutions blog.