4

What advantages would I gain by using the SP Services library in SharePoint releases 2010 and later? The 2013 (and even the 2010) JavaScript Object Model and REST API seem to cover a significant amount of surface area on what I might be interested in doing client-side.

Don't interpret this question as some dislike of the library on my part, I just don't understand why I might want to use it on a modern installation. :)

Improve this question

2 Answers 2

Reset to default
5

Pros

  • A wide range of SharePoint functionality is exposed with the SOAP Web Services, much of which is not available in CSOM

  • Allows anonymous access (assuming it is enabled for the underlying objects)

  • Works cross-site and cross-domain, assuming that the authentication model you are using allows it
  • Simpler syntax than the CSOM. Simply pass the required parameters to the Web Service operation, e.g., GetListItems
  • Built on top of jQuery, which is very good at ensuring cross-browser compatibility
  • Regularly updated and refined to be compatible with new versions of jQuery and to add new functionality based on user input
  • Works identically in SharePoint 2007 and 2010 (where the same Web Services exist – see chart)

Cons - The SOAP Web Services which SPServices wraps is “old” technology which only returns XML - Because the SOAP Web Services are older technology, they may not be supported as long as CSOM

link: When to Choose SPServices vs. the Client Side Object Model (CSOM).

Improve this answer
2
  • I see this article would have showed up in a web search if I had said "when should I use SP Services" -- the two viewpoints in the article above are significantly more illuminating than the pro and con bullets you've posted from the bottom. The point about anonymous access is well taken; I would challenge the first bullet though, especially in a 2013 environment, what is available in the soap web services that is not available in the CSOM or REST API? Perhaps you could elaborate?
    – John-M
    Aug 14, 2014 at 14:14
  • 1
    There are actually a lot of things available in SharePoint's SOAP Web Services that CSOM and REST don't yet expose. Take a look at what I've wrapped in SPServices (spservices.codeplex.com/…) vs. the available REST endpoints in SharePoint 2013(msdn.microsoft.com/en-us/library/office/…), for example. The key is to understand what you are trying to accomplish, not which library is "cooler".
    – Marc D Anderson
    Aug 26, 2014 at 23:59
4

It basically depends on your personal experience with the different technologies, there are many opinions out there with lots of pros and cons that may or may not be relevant to you. I personally very much dislike pure javascript CSOM because of all the context loading and SPServices was a good abstraction for that, but eversince I've used REST in SP2013 I haven't looked back. For any "special cases" I usually just build my own web handler (ashx) that I call through ajax.

What's good to know is that all client technologies in SharePoint are perfectly viable and it really depends on which you're most comfortable in using. I don't remember any serious disadvantage with any of them since SP2013.

Improve this answer
3
  • It seems SP Services does have (in my opinion) a couple of serious disadvantages: necessary inclusion of jquery and sp services on pages where you use it, and questionable forward support due to both jquery and sharepoint updates. Additionally, writing your own services to handle special cases is convenient, but often not practical for most implementations in large enterprise environments. I gave you an up-vote anyway though for at least having some original thoughts to contribute to the discussion :p
    – John-M
    Aug 14, 2014 at 14:21
  • Why do you think it's inconvenient? Because of file system/farm-wide deployment? Or are you simply talking about the cons of serverside development?
    – Christoffel de Gruyter
    Aug 14, 2014 at 15:06
  • I don't think it's inconvenient, if anything it's quite convenient when you can tack on functionality when and where you need - my comment is more related to the limitations of server-side development as you suggested - especially on large production platforms
    – John-M
    Aug 14, 2014 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.