REST API Limitations – Inherited Top Navigation and Master Page
Interactive Business Systems is now Planet Technology. Looking for a new job? We work with some of the biggest names in tech, and we’re hiring! Check out our open jobs and make your next career move with Planet.
While reviewing some requirements for a project, I noticed that they wanted an inherited Top Navigation and Master Page to be part of their site creation process in SharePoint 2013 On-Premises. One of the client’s requests was that we not use server side code (C#\VB). Since I’d never done this in REST API, I decided to do a bit of research into it and came to the following conclusions…
- Activating the SharePoint Publishing Infrastructure on a web in REST is possible, but the user needs to be a Site Owner and privileges cannot be elevated in REST without creating an App/Add-in and running it in the App Context.
- There is no property to allow for setting Top Navigation to inherit from the Parent when creating a web via REST API. This can theoretically be done after the web is created, but again the user would require the necessary permissions to do this unless done in an App/Add-in.
- Check out this post for a little more information
- The Master Page value cannot be changed via the REST API on a Team site template without being able to activate the SharePoint Publishing Infrastructure feature. I’m able to go in and access and even attempt to change the values, but it does not actually set the Master Page for the site. I could theoretically change web properties via REST, including the MasterURL property using a PUT request to the “/_api/web” endpoint passing in “MasterUrl” as a property being changed.
- This post spells it out nicely.
After going through the research and tinkering around I decided it would be best to tell the client if they want the Inherited Top Navigation and Master Page on site creation, we would be better off deploying a WSP rather than finding a “hacky” way to do it via REST/CSOM.