Monthly Archives: February 2014

I had reason to work with the SharePoint 2013 Search API via REST for the first time. I wanted to search for people, not documents. The key learning here is that you specify content sources via its GUID (or at least in this case). The following jQuery snippet shows how:

We’re telling SharePoint “Give me the title for all the Categories (Categories/Title). Get the actual values for Title by $expanding the Categories list.” (My RESTful paraphrasing is probably pretty loose, but this how I’m interpreting it).

If you’re doing this via JavaScript and using Fiddler to look at the output, you get something like this in return:

(The above is a JSON object)

Perform a People Search via REST

I blogged about this separately. The key is to specify a sourceid parameter whose value is the GUID of the Local People content source. (Content sources used to be called scopes and it’s my-oh-my so hard not to call everything a scope for me!).

This approach uses jQuery. In my case, my jQuery library is located in “../plugins.” You’ll want to change that to point to your favorite JQ location.

You can copy and paste that whole snippet into a Content Editor Web Part on a page and it should work just fine. You’ll want to change the end point of the API call and make sure you reference JQ correctly.

You don’t need to provide a content-length. Some blog posts and MSDN document implies that you do, but happened for me automatically, which I assume is being handled by the $.ajax call itself.

This line is required in order to avoid a “forbidden” response: "X-RequestDigest": $("#__REQUESTDIGEST").val(). There are other ways to do it, but this is pretty nice. I have lost the link to blog that provided this shortcut. H/T to you, mysterious blogger!

I wanted to add a link to the quick launch navigation the other day and SharePoint told me:

Pure text version of that is:

Ensure that the URL is valid and begins with either a valid character (a number sign (#) or forward slash (/)) or a valid supported protocol (for example, ‘http://’, ‘https://’, ‘file://’, ‘ftp://’, ‘mailto:’, ‘news:’).

“Blech and pox!” I said.

A workaround to this is to use JavaScript to find a known link in the quick launch and override its behavior.

To test this, add a new link to your test site thusly:

I used jQuery. To solve it, get some JavaScript and jQuery onto the page using your favorite technique and with a line of code like this:

The jQuery selector finds every <a> tag that has “Test URL replacement” in its name. You may want to find-tune that depending on your link and such.

The .click(function() overrides whatever SharePoint would have done when the user clicked. Make sure you “return false” or else it will do your stuff and then try to the href thing too, which is almost certainly not your goal.

This was done and test in a SharePoint online environment but should work well in 2010 and earlier too.

I’ve been working on a public facing web site for my SharePoint practice here in New York and it uses a lot of JavaScript and REST calls to show content.

During mainline development, I create a small dataset with just 10 or so rows in a custom list and my REST calls all pulled from there. Once I bumped up the list to have a few hundred rows of data to test for anticipated growth, I found that I was getting exactly 100 rows returned back on my REST calls.

This is a very simple thing to address. In my case (and I believe in most cases), the default REST calls to SharePoint (and possibly as an industry standard?) return 100 rows. To return more than the default, use the $top parameter on your call, as in:

GET /Insights%20Dev/_api/web/lists/GetByTitle(‘MockBlog’)/items?$select=ID,Title,Categories/Title,Blog_x0020_Author/Title,DatePublished,BlogSummary&$expand=Blog_x0020_Author,Categories&$filter=&$top=9999

I picked 9999 in this case since I know that growth-wise, there won’t be more than 200 or so rows added to this list in a year. If it becomes ungainly, we can implement some paging down the road.

You can get this error when you forget to include ID in the the list of fields to update. This, like a lot of these SP web services, is a bit counterintuitive since you need to include the ID in the ID attribute of the <Method> element. And you’re not updated ID and probably never want to in the first place.