Moving from SPServices to REST, Part 1

In this series, you’ll learn how to transition from the SOAP Web Services – which SPServices supports – to REST. If your organization is making a transition to SharePoint 2013 or Office 365 & SharePoint Online (and anything hybrid in between), this series will help you develop new patterns, migrate your codebase, use OData effectively and more.

It’s been a nice, long ride for SPServices. If you aren’t familiar with SPServices, it’s freely available on Codeplex, Microsoft’s waning open source repository.

SPServices is a jQuery library that abstracts SharePoint’s Web Services and makes them easier to use. It also includes functions that use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.

The Web Services that SPServices abstracts for you are the older SOAP Web Services, sometimes known as XML services, or ASMX services. As I’ve said repeatedly at conferences and in posts (like this one) before, I think we still have many miles to go with the SOAP Web Services. Microsoft officially “deprecated” the SOAP Web Services as of the launch of SharePoint 2013, but I can’t see them fully disappearing for a good long time given the number of different ways they are used.

Two API sets are still supported in the SharePoint 2013 framework for backward compatibility, but we recommend that you not use them for new projects: the ASP.NET (asmx) web services, and direct Remote Procedure Calls (RPC) calls to the owssvr.dll file.

See: https://msdn.microsoft.com/en-us/library/office/jj164060.aspx#DeprecatedAPIs

I started writing this series just after SPTechCon San Francisco in 2014, having talked to Andrew Connell and Scot Hillier about how I might be able to contribute to IT Unity for the site’s launch. Obviously the series fell by the wayside for quite a while, but these topics are even more relevant now than they were when they first came to me.

Like many of you, I drive an older model car. It is fun to drive, is comfortable and seems to be in great shape. The car may last me a while, yet from time to time I think about what I might want to drive next.

Moving from SPServices to REST is like deciding to trade in your reliable car for a model with more safety features. You should do it, eventually.

Photo Credit: “FIAT 600” by Andrea~S on Flickr http://ow.ly/wqxGN

At some point, we’ll all want to head into the dealer and get ourselves something shiny and new. To me, that something new is REpresentational State Transfer, also known as REST.

While SharePoint’s client-side object model (CSOM) can do a lot, it’s a SharePoint-specific technology. REST, however, is a Web standard. Many Web developers use REST to get their work done every day outside the SharePoint world. It’s time for those of us who develop on top of SharePoint to catch up with the rest of the Web development community. Most SharePoint developers have caught onto this reality in the last year or so.

When REST was first offered as an option in SharePoint 2010, it let us get some work done with lists, but that was about it. With SharePoint 2013 and even more so on Office365 with SharePoint Online and the Office365 APIs, the SharePoint team at Microsoft continues to give us more and more RESTful – or REST-driven – capabilities. New REST services have been introduced regularly and the existing services have been extended many times.

If you’ve loved working with SPServices, or at least you’ve gotten some good work done with it, this series of articles will help you to make the transition from the SOAP Web Services that SPServices wraps to the more open – and undoubtedly more robust over time – REST services offered in SharePoint 2013 and Office365. If you’re still running SharePoint 2007 or 2010 – as I know many of you are – this should still be a valuable series to you. By making some adjustments in your development style and the coding patterns that you follow, you can put yourself in an excellent position to move to REST when it becomes appropriate for you to do so.

Here are some of the things I plan to cover in this series:

  • New patterns I suggest you follow with your SPServices code so that you’ll be better prepared to move to REST when the time comes. A side benefit of these new patterns will be better modularity and reusability in your SPServices-based code.
  • You will learn ways to move parts of your code from SPServices to use REST even now with less effort than you might think. We’ll talk about where the most likely places in your codebase probably are and how to get started.
  • We’ll look at how the functionality in the SOAP Web Services maps to the current REST services and where there are still gaps.
  • We’ll talk about where OData comes in and how best to understand the OData componentry that sits under the SharePoint-specific implementation of REST. There are some differences from the standard (these gaps are narrowing all the time), and it’s important to know what those differences are and why they matter.
  • As Microsoft adds more functionality to REST in SharePoint 2013 and Office 365, I’ll write new articles in the series to augment the base set of content. It’s not your father’s Microsoft anymore – the SharePoint team is moving fast and improvements are going to be coming Fast and Furious (see what I did there?)

It’s hard to give up the old car that you’ve driven for years, but sooner or later, it’s time. Maybe the engine starts knocking too much or the springs in the seat get uncomfortable. Maybe you just want to try out something new. It is sad letting the old girl go, but at some point, it’s simply time. I once held onto a car until the engine simply stopped working. You don’t want to be in a similar situation with your SharePoint functionality built on top of SOAP. Let’s start to plan for the future, and let’s do it together.

Cooler with better design and safety features. Your new code using REST, using practices favored by the rest of the Web development community.

Photo Credit: “2014 Fiat 500” by Abdullah AlBargan on Flickr http://ow.ly/wqynJ

This article was first published on IT Unity on March 25, 2015. Visit the post there to read additional comments.

Great Resource: Responsive SharePoint from Eric Overfield

2015-03-20_10-55-33This week I was working on moving a design into SharePoint 2010. The design was made up of the standard sorts of things: HTML mockups with graphics, CSS, etc. The mockups are using Twitter Bootstrap as the styling framework.

I’ve done this sort of branding implementation many times, and it’s always interesting because what I get to start from is different every single time, even if it comes from the same designer. Over time we all change our approaches and styles because we learn better ways of doing things. That’s a good thing, but it means that every design implementation is like a new experience, albeit with many common components.

When I’m implementing a design in SharePoint, I find that there are use one of three basic approaches, regardless which version of SharePoint it is:

  • From the top down – In this case, I’m changing SharePoint’s master pages very little. We might want to change some colors, fonts, and basic functionality, but it still will look like SharePoint from a structural standpoint: banner across the top, Quick Launch down the left, etc. Here I just make a copy of default.master, v4.master, or seattle.master – depending on the version – and add some CSS and script references.
  • From the bottom up – This is the most extreme branding, where I start with a minimal master page and build things from the ground up. This is most common with Internet-facing sites, but can also be the case for an Intranet. Everything is customized in the master page: the HTML markup, the content placeholders and their placement, etc.
  • Something in between – This was the case with the current project. Even though the end goal is a site that look little like SharePoint, it doesn’t require a total disemboweling of the master page.

For the latter two bullets, we have some excellent choices available to us which have been created by the SharePoint community. To me, the shining lights here are Randy Drisgill (@drisgill), Eric Overfield (@EricOverfield), and Kyle Schaffer (@kyleschaeffer). (That’s an alphabetical list by last name; they are all equally awesome.)

All three of these brilliant guys have free starter solutions on Codeplex:

In this particular project, Eric’s master pages seemed to be the best match. As I was struggling to get the ribbon to behave with Bootstrap, I realized that I didn’t need to fight the battle again myself and that Eric’s master page would probably be just the tickets. Indeed it was! After grabbing his project, I was able to get the design up and running in just a matter of hours.

If you’re even considering coming up with a responsive and/or Bootstrap-driven design, save yourself a lot of trouble and look at Kyle or Eric’s work It probably won’t be exactly what you want out of the box, but they have solved a huge majority of the problems you’ll run into already. This is what makes the SharePoint community so awesome. This is really deep capability and work that is out there for you to use – for free.

 

Simple OneDrive Better Practice

This morning I saw a post on Facebook (the other Yammer) from my friend Jasper Oosterveld (@jasoosterveld):

Great start of the morning! OneDrive for Business Sync lost my Visio file with my sitemaps and page lay-outs. Un&*@(believable….

It truly pains me to see posts like this for several reasons.

First of all, I hate to hear that someone has lost some work. Technology is supposed to make our lives easier, but sometimes I miss index cards.

OneDrive-forBizMicrosoft-OneDrive-logo-largeMore importantly, OneDrive ought to be awesome no matter which flavor you are using: OneDrive for Business, OneDrive [for Consumer], or whatever other adjunct flavor you may run into. (It’s OneDrive, but there’s more than one!)

The OneDrive team is making huge strides on the reliability of the product  – six months ago this would have just been a flat out rant – but there still a way to go. For example, here’s a recent post about how Managing your work files in the browser keeps getting easier on the OneDrive blog.

As I replied to Jasper, I’ve found that the most reliable approach using OneDrive for Business is to edit in one place only. By this, I mean to always edit locally or always edit in the host Document Library. What I’ve found works best for me is to use the Document Library only for central storage and always edit locally. It’s faster (the file is here already) and I know I’m backing it up with CrashPlan regularly.

OneDrive (none of the flavors) is *not* a backup mechanism – it’s a syncing mechanism. It’s main purpose – at least for me – is to make sure that I can access my files from any device. If I edit a file on my Surface Pro 3, then I know that I’ll see those edits on my ASUS laptop and vice versa.

OneDrive is getting better and better, but for now it requires a bit of caution. At some point in the not too distant future, I plan to throw that caution to the wind when OneDrive lives up to its promise.

 

Arctic SharePoint Challenge 2015 Notes – Part 2

A few weeks ago I posted from the Arctic SharePoint Challenge in Oslo, Norway. Now that I’ve been home for a while, I *still* think it was a really cool thing to have the chance to attend. I was flattered to be asked to give a keynote on the first day and to act as a jurist (or judge – depending on who was talking) for the event.

Here I am with the other judges (from Left) :Christian Nesmark, Harald Fianbakken, and Chris Givens. We only had one robe.

ASPCJudges

I wanted to post the links to each team’s repository, if only to save them for my own use down the road. The stuff these folks came up with was truly impressive!

You can read the narratives behind the code on the blog where each team posted their progress and requests for the valuable badges.

Enjoy!