SharePoint webservice vs. custom webservice

Question

I'm wondering what experienced SharePoint developer would advise me to use if I want to access SharePoint data remote, the SharePoint built in webservices or a custom webservice.

What are the pros and cons for these both options?

Answer 1

If the SharePoint web services are capable of doing everything you want them to do (and they do expose access to a lot) then there is absolutely no need to write custom web services that do the same job. I have had conversation before with some developers who find the SP Web Services "difficult" to work with, however I view this is an opportunity to learn rather than a reason to re-write.

I have been using MOSS 2007 for three years (since early betas) and, in my experience, have never seen a need to write a custom web service to expose MOSS data to an external application.

Hope this is helpful to you

Stuart

Answer 2

The SharePoint Web Services are near and dear to my heart (see my jQuery Library for SharePoint Web Services). I agree with Stuart above. Why write something custom if there's already something there with the functionality? I've found that there are a few little things that I wish that the Web Services exposed (removing the linkage between the source and destination documents after a CopyIntoItems, as a recent example), but in general, what you can accomplish is pretty amazing. Start with what's there and only if there's a gaping hole should you write your own Web Services.

M.

Answer 3

The SharePoint web services can be difficult for some developers or systems to consume. There are definitely some SharePoint-isms in there. For many common tasks we have written some reusable wrapper web services that make them more approachable for some purposes. For example we developed something for the list web service to make it easier to bring the data to our data warehouse or non-Sharepoint systems.

Answer 4

An often overlooked fact about the OOTB web services is that they have a very slim impact on the server in terms of custom developer code.

SharePoint development can be a veritable mine field of looping the right way (to avoid too many calls to stored procedures in the back end) and disposing correctly (to avoid mem leaks) etc.

The OOTB web services is coded by the product team and testet thorougly and hence has an optimal footprint performance wise on your solution.

Its a fact that no matter how well you try to avoid it, every line of custom code slows down your box, so if you can get your data from one of the OOTB web services, its a good and safe approach with little impact on your production box.