<p>Are people still writing <a href="http://zeroc.com/blogs/michi/" rel="noreferrer">SOAP services</a> or is it a technology that has passed its <a href="http://www.addsimplicity.com/" rel="noreferrer">architectural shelf life</a>?  Are people returning to binary formats?</p>

[{'answer_id': 38465, 'author': 'Brad Wilson', 'author_id': 1554, 'author_profile': 'https://Stackoverflow.com/users/1554', 'pm_score': 3, 'selected': False, 'text': "<p>The alternative to SOAP is not binary formats.</p>\n\n<p>I think you're seeing a surge in the desire to leave the complexities of WS-* behind in favor of REST and JSON, because they're much simpler to use and don't require frameworks to be used successfully. The problems that WS-* ostensibly tries to solve aren't problems for most users, but they have to pay for the complexity any way.</p>\n"}, {'answer_id': 38487, 'author': 'erickson', 'author_id': 3474, 'author_profile': 'https://Stackoverflow.com/users/3474', 'pm_score': 3, 'selected': False, 'text': "<p>I still write WS-*&ndash;based services. Somewhat surprisingly, I've had less trouble with them when trying to inter-operate with less capable developers. This is because if I send them a WSDL file, they know how to crank it through their tool and get an API they can call, while being blissfully unaware what is happening under the hood. To give customers a REST-ful service, I have to start talking to them about HTTP and XML, which they really don't understand as well as they think they do, and then I start getting a headache.</p>\n\n<p>In other words, to be successful with REST, both the service provider and consumer have to know what they're doing (and they can keep things simple and come up with a great, non&ndash;WS-* solution). With WS-* technologies, it can still succeed even if only one party has a clue. </p>\n\n<p>I think, however, that REST-oriented standards that are much less complicated than current WS standards, will eventually emerge, and when that happens, comparable tools will be available too.</p>\n"}, {'answer_id': 38519, 'author': 'kemiller2002', 'author_id': 1942, 'author_profile': 'https://Stackoverflow.com/users/1942', 'pm_score': 2, 'selected': False, 'text': "<p>I wouldn't consider SOAP legacy at all.  REST vs. SOAP is really just the continuation of the debate of COM/CORBA vs. HTTP POST/GET etc.  SOAP is nothing more than an updated version of the same principles defined with C and C (contracts, providers, consumers etc.).  It's just that has appeared to SOAP succeed (at least partially) where the other two failed (and it could be that SOAP just has a better marketing team), that is that SOAP really does allow to different systems to connect rather easily compared to it's predecessors.  That being said, it still suffers from the same drawbacks that COM/CORBA did...it can get really complex.</p>\n\n<p>I think REST is just coming back into style at the moment.  It's nothing new, people are just taking another look at it. Look at the web.  It's REST and it's been around for years.  5 years from now people are going to look back and say the same thing about it being legacy and the need to change.  It's the nature of software development.  Everything goes in cycles.</p>\n\n<p>The debate about which one is better is going to be just like the tabs vs. spaces debate.  There are going to be people on different sides swearing that one is better.  Really in the end, they both accomplish the same goal.  Sure one will be a better solution than the other in some situations, but in the end neither will be superior 100% of the time. </p>\n"}, {'answer_id': 38522, 'author': 'conmulligan', 'author_id': 1467, 'author_profile': 'https://Stackoverflow.com/users/1467', 'pm_score': 2, 'selected': False, 'text': "<p>I think so. RESTful solutions are more and more sensible for the vast majority of use cases; the complexities of SOAP and other RPC technologies just aren't worth the effort anymore.</p>\n"}, {'answer_id': 123024, 'author': 'maxfurni', 'author_id': 20832, 'author_profile': 'https://Stackoverflow.com/users/20832', 'pm_score': 2, 'selected': False, 'text': '<p>We were using SOAP, but since we control both messaging endpoints (thick client out on the web connecting to our servers) we decided that the "lingua franca" of XML wasn\'t offering any real benefit.  Instead, we\'re experimenting with binary serialization via Google protocol buffers, and like everything we\'ve learned so far.  It\'s somewhat CORBA-esque, but doesn\'t make me grumpy the way CORBA did.  Still haven\'t found the best fit for the RPC layer, but pretty sure the payload will be protocol buffers.</p>\n\n<p>The point I\'m trying to make is that if you control both sides of the conversation, there are significant efficiency advantages in bypassing the XML tax.</p>\n'}, {'answer_id': 6614446, 'author': 'uvesten', 'author_id': 494626, 'author_profile': 'https://Stackoverflow.com/users/494626', 'pm_score': 1, 'selected': False, 'text': "<p>Yes, some people <strong>still</strong> are (and now it's 2011!). I think the main reason is that MS WCF automatically generates SOAP bindings. The horror. </p>\n"}, {'answer_id': 6614628, 'author': 'Paul Keister', 'author_id': 19500, 'author_profile': 'https://Stackoverflow.com/users/19500', 'pm_score': 1, 'selected': False, 'text': "<p>It's impossible to define what the best technology solution is without considering what the problem is, in other words, what the context is. Both REST and SOAP have their place. If you have a high traffic site and a development audience who is comfortable with REST, then SOAP would be a bad choice, primarily because the message size is so incredibly bloated. If you have small scale site with a modest development budget, then SOAP will be a superior choice due to automatic proxy generation from WSDL. To make a fair comparison, it should be mentioned that implementing a REST conversation takes more development time and therefore is more expensive, a very relevant fact for your boss.</p>\n\n<p>While it is true that SOAP is a more complicated protocol, in my experience this doesn't translate to maintainability issues. That's because messages ride on HTTP and can be easily debugged just like REST message, and the SOAP stacks available on major platforms are very solid.</p>\n\n<p>The complexity of SOAP is of course an advantage if your requirements include sophisticated items like federated message security. On the other hand, these kind of requirements are not seen that often in my experience. The WS standards committee may have been vulnerable to some YAGNI issues. Now that web service communication is commonplace, it's turning out to be simpler that was originally envisioned.</p>\n"}]
['https://Stackoverflow.com/questions/38463', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/3305/']