<p>My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based). </p>

<p>Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.</p>

[{'answer_id': 6100, 'author': 'Brian Lyttle', 'author_id': 636, 'author_profile': 'https://Stackoverflow.com/users/636', 'pm_score': 6, 'selected': True, 'text': '<p>Document versus RPC is only a question if you are using SOAP Web Services which require a service description (<a href="http://en.wikipedia.org/wiki/Web_Services_Description_Language" rel="noreferrer">WSDL</a>). RESTful web services do not not use WSDL because the service can\'t be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed <a href="http://en.wikipedia.org/wiki/Web_Application_Description_Language" rel="noreferrer">WADL</a> as a way to describe REST services.</p>\n\n<p>Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a <em>Service Reference</em> or <em>Web Reference</em> in Visual Studio.</p>\n\n<p>Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.</p>\n\n<p>Document/literal versus RPC for SOAP services are described on this <a href="http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/" rel="noreferrer">IBM DevelopWorks article</a>. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST\'s simpler approach is superior.</p>\n'}, {'answer_id': 9050, 'author': 'UberAlex', 'author_id': 170, 'author_profile': 'https://Stackoverflow.com/users/170', 'pm_score': 1, 'selected': False, 'text': "<p>BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.</p>\n"}, {'answer_id': 45558, 'author': 'Lior Bornshtain', 'author_id': 186252, 'author_profile': 'https://Stackoverflow.com/users/186252', 'pm_score': 3, 'selected': False, 'text': "<p>As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.\nIt is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF). \nTherefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.</p>\n"}]
['https://Stackoverflow.com/questions/5598', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/699/']