Latest REST topics

One of the things I’ve been working on lately is harvesting a complete listing of all the site collections in a tenant, including as much metadata as possible. Some of the metadata I’m looking for revolves around adding governance to managing your catalog of sites, especially in a large tenant. For sure I think the SharePoint product group has visibility into the needs here but to get full fidelity might take significantly longer than you can wait. So, if you’re looking to create yourself a site catalog how do you go about it and what information is available to you. In this post I’m just going to touch on each of the ways you can harvest this information and what additional metadata each provides as well as what other ways you can get information. [Continue Reading]

A recent comment on my blog post “SharePoint time, is not your time, is not their time.” has prompted me to create a short addendum post that specifically references updates and how your thinking might differ from displaying SharePoint date/time values. To recap our example, I was discussing how to manipulate the date values to have your client-side code mimic (or not) the regional settings of your SharePoint site. The question was raised about how to deal with dates when doing POST to a SharePoint list or library from your client-side code. [Continue Reading]

Introduction When I last left you (in Part 3) we had completed the round-trip journey that is learning all the facets to accessing the Microsoft Graph API (MSGraph) through an Azure Application and the ADAL.js library. A significant portion of our time was spent simply on the different ways to leverage ADAL.js depending on the framework you were using. In this next installment we’re going to go one step further and streamline our implementation of ADAL, in AngularJS specifically, but with broader implications to any web based framework. [Continue Reading]

If you develop client side solutions for SharePoint you’ve either run into this or you will run into the following scenario. SharePoint stores all its date/time fields in UTC time. The site collections, sites, and the users, can have their own time zone settings. If you’re using SharePoint out of the box because all the content is rendered on the server and pushed to the client with all the date/time translation has been done for you. This makes wonderful sense, except when you try and write JavaScript against those same data points. The REST endpoints that return the data for you give you the date string in a format that is specific to the regional settings of the person asking for them. Sadly, this doesn’t translate as well to JavaScript as you might like. I’ve set up a scenario to illustrate the point with a couple of manipulations you can make depending on your desired goals. [Continue Reading]

Introduction In Part 1, I discussed the background and setup information you would need to successfully embark on a client site widget for SharePoint that accesses the Microsoft Graph API (MSGraphAPI). In Part 2, we went in depth to the various ways of utilizing the adal.js and adal-angular.js libraries for authentication. Now, here in Part 3 we’re going to get right into the nuts and bolts of a real solution that does the following: [Continue Reading]

Introduction In Part 1 of this series I covered all the setup needed to start your Microsoft Graph API (MSGraphAPI) client side widget. In Part 2, we’re going to dive into the many ways to use adal.js and its counterpart adal-angular.js. I’ve included the same resources I included in Part 1, under the section for ADAL you’ll find a lot of references to Cloud Identity blog by Vittorio Bertocci who has blogged extensively on the library, explaining in depth the technical workings of it. I encourage you to read those posts I’ve included below to get a complete understanding of the library. Also, included in the references is a post about utilizing ADAL in the SharePoint Framework (SPFx). As is, ADAL was never meant to be used as part of a widget architecture as ADAL isn’t a singleton, so if you have multiple web parts on your page all referencing ADAL you’re going to have issues. The post Call the MSGraphAPI using OAuth from your web part (no longer available) gives you an extension that will help isolate ADAL so that you can utilize it as part of a more strongly developed widget pattern. Since my demo is just that, and since my solution will be the only one running on the page that uses the ADAL library I’m not going to address those modifications here. But, I encourage you do so if that is part of your use case. [Continue Reading]

When Marc and I were at Ignite this past September, #SharePoint was the most tweeted hashtag. We heard a lot about the new SharePoint Framework (SPFx), which was clearly the focus for developers. But another oft-discussed technology topic centered on the expansion of the Microsoft Graph API (MSGraphAPI). It’s clearly going to be the API of choice going forward to access all Office 365 content, but its maturity is still early days. At Ignite, Microsoft announced the beta endpoints for accessing SharePoint through the Microsoft Graph API. Overall I think this is a good thing, as the API has significantly better adherence to the OData standard compared to the SharePoint REST services. That said, as users of the SharePoint REST services we’re very used to the simplicity of those calls and we literally pay no attention to authentication if we’re operating on SharePoint pages. The tokens we need are already made available right on the page, we just pluck them out, and so there’s little effort. [Continue Reading]

A quick post today to augment what’s out there in the “Googleverse”. I needed to create a Document Set in client side code, and went out to find the appropriate calls to make that happen. To update the metadata on the folder you create (which is all a Document Set really is under the covers), you simply make an “almost” normal list item update call. So the following is the various “functions” you need and how to string them together to do this task. As you read through, I’ll point out in the code where other older posts on this topic steer you wrong. [Continue Reading]

I’m constantly trying to remember which way to encode content when making calls to the server while developing client side solutions for SharePoint. Usually it’s some form of JavaScript’s encodeURI()/encodeURIComponent() functions… but this latest one gave me a bit of trouble until I finally figured it out which encoding to use and, almost as important, when to apply it. When making RESTful calls to update or create data in a SharePoint list you must include the “__metadata” (two underscores followed by ‘metadata’) property in the information object you send on the data property of the call. If you have a list with the internal name “Clients” and your data property object is called “item” then you would do something like the following: [Continue Reading]

Marc and I discussed in our August Sympraxis Newsletter starting a blog series to share what we’re learning while implementing a SharePoint client side development process. So this is my first post on the topic, and here’s a link to his first post… it’s interesting to see how different our perspectives on the process were. In all my previous experience I’ve either been in a team or in a regulated industry or both. All of these scenarios dictate that you have at least some process in place and in the case of the regulated pharma industry, rigorous processes in place. [Continue Reading]