SPServices: What About Deprecation of the SOAP Web Services?
SPServices user JSdream asked a question in the SPServices Discussions on Codeplex the other day that’s worthy of a more prominent response.
Should we, who use SPServices, be concerned at all with Microsoft recommending not to use either the ASMX web services in SharePoint 2013 (http://msdn.microsoft.com/en-us/library/office/jj164060.aspx#DeprecatedAPIs) or the owssvr.dll (I used this one a lot when doing InfoPath stuff) for development purposes?
The Choose the right API set in SharePoint 2013 article is an important one, for sure. In it, there’s pretty clear direction about which API to choose based on the specific requirements of the solution you are building. As with anything, though, there’s a strong dash of “it depends”. It depends on things like your available skills, the device the code will run on, etc.
I would say that we should all be “cautious” rather than “concerned”. The SOAP Web Services are used by many parts of SharePoint still, with the most prominent being SharePoint Designer. If you sniff around in the traffic between processes, you’ll spot other places as well.
That said, deprecated is deprecated. If you build your solutions with the data access layer separated out from the business logic layer, you should be able to replace the calls if and when it becomes necessary.
I am not aware of any official specific time frames for the SOAP services going away, and the Product Group would need to give us a good, long lead time because lots of code depends on it, SPServices or not. Many people have built managed code-based solutions which use the SOAP Web Services as well. GetListItems is a workhorse operation no matter how you build your solutions.
There are many things you simply cannot do with REST yet, though in many cases CSOM may provide better coverage. If you are using SPServices for the operations which aren’t available in REST or CSOM, obviously you’ll want to continue doing so until there is a viable replacement. The REST coverage is improving steadily. (See Overview of SharePoint Conference 2014 and new content for developers for some information.) Keep in mind, though, that the majority of improvements will end up in Office365 first and in the SharePoint Server product at some point later or perhaps not at all. So your time horizons and cloud plans are also critical decision factors.
[If I had to put my money on a horse, it’d be REST over CSOM over the long term.]
All that said, if you are starting a new project on SharePoint 2013 of any significant size, you should be considering using the App Model, CSOM, and REST. SPServices may still fit in there somewhere, so don’t toss it out with the bath water just yet. I’ll continue evolving it as long as it has people wanting to use it. I think I still have plenty of things to do.
“I’ll continue evolving”….translates to hold you horses , spservices will move from SOAP to REST services in some time ?
Interesting interpretation, Rajat. I wouldn’t rule it out, but it would be a *lot* of work. Also, since it’s far from parity between SOAP and REST at this point, it would have to be a mix.
M.
That’s actually what I have done for my customers, build a library that mixes SOAP and REST… and also owssvr, and RSS, and so on. Because there’s no reason to restrict ourselves, right ;-) As Marc says, it’s a lot of work, and you need to make choices, or else you end up with 500 kb of JavaScript!
If you are looking for a way to abstract REST, the Breeze library looks promising: http://www.breezejs.com/
If you’re interested in how Breeze and SharePoint can work together via REST, check out Andrew Connell’s excellent work in his series of blog posts, starting with BreezeJS Makes Client-Side SharePoint 2013 REST Development a… BREEZE.
M.
I’d say that a key factor is whether you are in control of your SharePoint environment or not. From experience, on Office 365 Microsoft won’t give you much time to adjust, so you’d better prepare a plan B for critical processes. On premises you have the option to postpone an upgrade or service pack.
That’s a great point, Christophe, though the folks running Office365 are working hard to make what’s coming more transparent. Even if they announce what’s coming well in advance, at least currently you have little control over whether you get the updates.
Obviously (at least you and me), there’s a big different between SaaS and running your own servers.
M.
I’ve formed the opinion that the REST API just doesn’t cover all the bases yet. I tried to build a search screen and came up against the massive stumbling block of being unable to search against multi-line fields (or ‘notes’ as the error message tells me) or multi-valued lookups. Thank goodness I can fall back on SPServices.
As you said Marc, there is not parity between SOAP and REST, and until Microsoft can offer that I’m sure full deprecation has a long lead time.
Marc said there’s no parity between SOAP and REST, but I don’t think he was referring to list queries. REST accepts CAML queries, just like SOAP, so any CAML query you build for SOAP should also work on REST.
Exactly, Christophe. If all you’re using the APIs for is effectively GetListItems, you have options all over the place. It’s the coverage beyond that and some of the other core capabilities where the Venn diagrams diverge significantly.
M.
Thank you for expanding your answer Marc
Sure thing. You’re not the first person who has asked. Now I have something to point to. Thanks for the question!
M.
Thank you for the nice analysis regarding the future of your lovely API in the context of owssvr.dll/ASMX web services.
I have a tangential question regarding the JSOM API that MSFT has on this blog post, http://msdn.microsoft.com/en-us/library/office/jj164060(v=office.15).aspx.
It says that if you want to “Create an ASP.NET web application that performs create/read/update/deleted (CRUD) operations across a firewall on SharePoint data or external data that is surfaced in SharePoint by a Microsoft Business Connectivity Services (BCS) external content type” use JSOM. Are they talking in the context where the ASP.NET application is already integrated inside the SharePoint site?
Thanks