In this post, I’m going to create a better CORS Wrapper for SharePoint REST operations, and demonstrate using it for CRUD operations on a Picture library. First, I want to remove the dependency of jQuery, using fetch instead. As I covered in a previous post, Ugly SPA Revisited using Fetch and REST
, fetch is new enough and implementations are spotty enough, even in evergreen browsers, that I will need to polyfill fetch and ES6 promise in order to support a reasonable cross-section of browsers.
By implementing the full range of CRUD operations on document libraries, we’ll have an opportunity to see if there are other issues that need to be addressed in our wrapper. My last post really only did one simple REST operation across CORS boundaries.
Continue reading “A Fetch-based CORS Wrapper for SharePoint REST”
In this post I’m going to demonstrate a CORS Wrapper for postMessage operations, specifically in SharePoint, and intended to make CORS operations as simple as the Ajax operations we’re more familiar with. I’m going to develop the same simple pages I used in my last post, only using the CORS Wrapper this time. Then I’ll dump the CORS Wrapper on you. I’m not going to talk a great deal about the code, I’ve included a ridiculous number of comments in the code to explain what I’m doing.
And yet, in my experience, a lot of developers think this is too complicated and don’t want to deal with it. I think the reasons for this are twofold:
- SharePoint and it’s web services are already complicated. First, there’s a bunch of them, and they all take different parameters. And you need to set different headers depending on what you’re doing. And is it a GET, or POST, or MERGE. And they’re not very well documented, although that’s getting better. There are plenty of simple examples, but few complex ones (for instance, a lot is left to the imagination when it comes to filters or how lazy loading works).
- While postMessage does not add a ton of complexity, adding any complexity at all makes developers groan in agony (mostly because of reason 1).
Looks like an opportunity for some sort of CORS Wrapper or library. Deal with the complexity once, and forever more use the library to hide most if not all of the additional complexity.
Continue reading “A Light-weight CORS Wrapper for SharePoint REST”
Continue reading “REST Calls Across HNSCs (CORS)”