In my previous post I discussed how you can export Web Parts using CSOM. But did you know that you can also do it using REST?

Remote provisioning and exporting Web Parts

For a while now Microsoft has been advocating using remote provisioning instead of the SharePoint solution framework for provisioning SharePoint customizations in a structured and repeatable manner. The concept of remote provisioning is based on using SharePoint remote APIs to deploy assets and configuration to SharePoint environments. These remote APIs can be accessed in a number of ways: from PowerShell cmdlets to JavaScript.

Although the word provisioning implies deploying, often it also involves exporting existing SharePoint configuration. Be it for avoiding duplicating assets or removing obsolete elements, the ability to export SharePoint configuration allows us to build powerful deployment mechanisms that involve little to none manual intervention.

Only until recently, SharePoint remote APIs didn’t support exporting Web Parts. The only way to do it was to use the /_vti_bin/exportwp.aspx page which has some limitations, amongst which the lack of support for OAuth. Luckily, with the March 2016 release of SharePoint Online CSOM this has changed and the LimitedWebPartManager now supports exporting Web Parts.

CSOM vs. REST

In my previous article I showed you how you can use the recent update to SharePoint Online and use the Client-Side Object Model to export Web Parts. If you however build solutions on many different platforms or you simply prefer to use REST over SDKs, you might be wondering if it’s possible to export Web Parts using REST. Yes, it is possible and here is how you do it.

Export Web Parts using REST

In order to export a Web Part using REST you need to issue the following POST request:

POST /_api/web/GetFileByServerRelativeUrl('/pages/default.aspx')/GetLimitedWebPartManager(scope=1)/ExportWebPart HTTP/1.1
Host: contoso.sharepoint.com
Origin: https://contoso.sharepoint.com
X-RequestDigest: 0xEDDA967E80461A336DFA5F977E314C228517D7C4E1618C1E170804583665E55C38F9E6C6C9944C59E8B50B9CA918937E35E005648927D7482C4B974BDFD9EE2F,27 May 2016 06:59:24 -0000
Content-Type: application/json
Accept: application/json;odata=nometadata

{ "webPartId": "468a7c31-053b-41b3-9e7e-d658a3ecb7fb" }

As you can see, the payload must be set to the Web Part ID that you want to export and the request Content-Type must be set to application/json accordingly. Just as for any other SharePoint POST request you need to provide the request digest which you can obtain by issuing a POST request to:

https://contoso.sharepoint.com/_api/contextinfo

If the request was successful, the response will contain the XML of the particular Web Part, assuming it has exporting enabled.

Inconvenient Postman and SharePoint POST requests

When testing REST APIs I like to use the Chrome extension called Postman. Postman allows me to easily compose the different requests and set their headers and payloads as necessary. It also works both on OS X and Windows. Unfortunately there is a slight inconvenience when using Postman with testing POST requests to SharePoint APIs.

Postman is available in two forms: there is the old extension, that works inside of Chrome, and then there is the new extension which is also installed in Chrome but which works as a separate application. Personally, I prefer the old extension because it’s sharing cookies with the browser. This allows you to just test SharePoint APIs without any additional authentication effort. Unless you want to test POST requests.

If you try to issue a POST request to SharePoint APIs using the old Postman extension, all you will see is a 403 Forbidden response.

If you open the Chrome Developer tools and examine the outgoing request, you will notice that Postman sets the Origin request to its URL which is exactly why the request is failing.

Unfortunately the old Postman extension doesn’t allow to set some request headers such as Origin rendering it useless for testing POST requests to the SharePoint API. Luckily, you can use the new Postman extension instead.

As mentioned before one of the drawbacks of the new Postman extension is that it operates as a separate application outside Chrome. The consequence of that is, that it cannot use cookies already present in the browser. There is however another extension, called Postman Interceptor, which you can install and enable in Postman and which will allow you to use cookies already present in the browser.

When you try to issue a POST request to SharePoint API, don’t forget to set the Origin header to the URL of your SharePoint site. With that, things will work just as expected.

With the request digest obtained you can now call the ExportWebPart endpoint to export a Web Part:

Summary

Using remote provisioning techniques is the recommended approach to deploy SharePoint assets and configuration. With the recent updates to SharePoint remote APIs we can export Web Parts both using CSOM and REST. This allows us to build powerful deployment mechanisms that involve little to none manual intervention.