As someone who recently had to deal with a system with two different (incompatible) SOAP services, I fully endorse the message behind this site.

Luckily my exposure seems to be restricted to legacy and enterprisey stuff nowadays.

Hi - I'm Josh - the guy behind Stop SOAP.

There is no political intent behind this site. It is meant to be a joke. A joke with a grain of truth.

Backstory: I was waiting for a conference call, saw that stopsoap wasn't registered and put this together in 15min.

Deeper backstory: I'm the co-founder & CEO of Simple.com. We deal with many SOAP APIs. The upside is that SOAP provides very clear specifications as to how the API is supposed to work. The downside, is that things rarely work as expected. It is frustrating, but such is life in banking.

On a more serious note, We're Hiring. If you'd like to work at Simple, where we replace you bank & give you clean REST APIs to your finances, check us out: http://simple.com

Well, you may soon be the accidental hero who saved the world from slippery things.

Related: The S stands for Simple, http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-... and Please drop the SOAP, http://thecoffman.com/2011/01/25/please-drop-the-soap .

protocols with simple (or lightweight) in their name usually are anything but.

Not a coincidence. Simple to implement != simple to explain to your boss (`it's standard industry practice'). The name is meant to sell the standard to non-techies.

SOAP is no more the acronym of Simple Object Access Protocol since version 1.2

That's no excuse (and if you read the article you'd know that it acknowledges this fact).

Agreed, When i started SOAP around 2000, it was very simple. After that we for more into the awful WSDL 1 (WSDL 2 is better). But the number of WS-* and the different implementations that are all incompatible is just a nightmare.

In 2001 I gave a talk (I believe at OSCon, to a packed audience) titled "Why SOAP Sucks". I started with a print-out of all the specs required to implement SOAP fully (there were lots of incomplete implementations around at the time, but barely any complete ones). It was more than two reams of paper (around 1100 pages of spec, if I recall). It had quite an "impact".

IIRC, the Table of Contents for the SOAP spec is bigger than the entire XML-RPC spec, yet SOAP offers little practical advantage. Luckily many new RPC implementations bypass both SOAP and XML-RPC and are looking to REST. $deity help all of us who need to work with legacy SOAP, however...

I can totally relate to these two articles, having recently attempted to write a .NET SOAP client for a web service that uses the (non-standard) SOAP with Attachments method for sending binary data. For something that was created to provide simple interoperability, SOAP is rife with a ridiculous number of inconsistencies and competing mini-(non)standards.

Finally, a legit movement for us non-americans!! How are we supposed to protest against this? cover our pages with bubbles?

You must stop bathing for one week and blog about the results.

I'll admit to being completely ignorant about the benefits of using SOAP to communicate between servers. However I can say that for server->client communication it is the worse data representation I've ever had to work with and I genuinely hope we see the end of it. JSON maybe not be perfect, but it's so much better at delivering a structured data model then xml is.

I think I'd like JSON as a data representation a lot more if schemas for it were more prevalent. I've noticed it's a lot harder to generate valid JSON -- or rather a lot harder to escape data. With XML, this is fairly trivial. Granted, my use case is considerably different from most.

The other idea from SOAP I'd love to see applied to ReST is a descriptor document for the API. Given how poorly many ReST APIs are documented, I do miss the good 'ol WSDL. Plus, it gave me some measure of security that the API didn't change.

The strictness in generating valid json is exactly why i like it so much. I've worked with too many SOAP services with nodes and attributes thrown lazily around the document simply because xml is so unstructured. I do agree however that json could use a few more built-in data types to handle more complex use cases.

Does WADL provide what you liked about WSDL?

http://www.w3.org/Submission/wadl/

I haven't heard of this before. But I'll be checking it out. Thanks for the info.

You seem to be confused between SOAP and Restful XML Web Services? They are different...

You don't think you can replace one with the other?

There's also XMLRPC which is as simple as JSON and still XML

More tragic than HN becoming an advocacy site (the beginning of Slashdot's demise) is how many comments here don't get the joke.

The population of HN isn't just anti-SOPA because it's fashionable. SOPA would directly affect small internet businesses by putting the onus of copyright policing on site owners. Considering how many of the HN startups have any user generated content at all, it's a real concern for the vast majority of them. To not advocate against SOPA would be foolish.

Since when is being a web programmer a prerequisite to participating on HN?

I think what the OP meant is that this story is meant as a parody of the avalanche of "sopa is evil" posts lately. Whether you know what SOAP is or not is beyond the point.

Slashdot was always an advocacy site. Rob Malda posted about a similar action he took in 1996, before /. got its name. https://plus.google.com/u/0/105030465637303791249/posts/MTYL...

I agree. Sure discussions about SOPA have their place here, but lately it just felt like a bit echo chamber where you have the same people preaching to the choir using the same arguments over and over again.

If I look at the homepage right now it seems half the posts are "site XXX blacked out to protest SOPA". Do all those need a separate story? The redditization of HN is running wild.

Will september ever end?

Indeed. Another irony, the Cheezburger Network sites are using a pop-up complaining about SOPA, when arguably they are just the sort of site there is a legitimate complaint about, as they routinely rip off other people's comments, and bask in the ad revenue.

I'm against Stop SOAP. SOAP is a jobs-protocol.

In the current economy, consultants specialized in fixing convoluted web applications need us more than ever.

I agree. We need SOAP to stop the JSON loving bit thieves trying to steal our intellectual overhead (IO). Don't drop the SOAP!

I was thinking, Spanish people must be wondering, "what do all these nerds have against soup?".

And all english-speaking people must think, "what do all these nerds have against soap?".

these nerds - they rarely shower !!!

This has circulated recently:

http://www.en2palabras.com/f10/mafalda-nos-explica-que-es-la...

Mirror:

http://www.taringa.net/posts/info/13583646/Mafalda-nos-expli...

Yep, every time I ask a non-nerd what they think about SOPA, they answer "Why, it's delicious!".

Someone went searching for "Stop SOPA" and discovered something brilliant from their typo.

I'm wondering how it's technically possible for a submission with over 500 up-votes to be flagged to the point of being pushed off the front page; interestingly, it was not a gradual departure, as you'd expect, but rather it seemed to move instantly, from the top spot, to number 33 or 34, on the second page.

I think it's terribly important that it be possible for the community to reflect, critically: SOPA is a serious issue, one we should all be concerned about, and more importantly taking action against. However, there is a point where it becomes an echo chamber, where we are preaching to the choir. Having nearly every submission be yet another "X is blacked out" does not necessarily correlate to communicating to our lawmakers that we do not want this legislation to pass.

Clearly this subtle, yet provocative submission's intent to communicate such a critique was understood by a number of people. I'm still unsure how it ended up bumped so quickly, but whatever the case, I hope the point wasn't entirely lost on those of you who didn't appreciate it.

I suspect the absolutely dismal state of the comments helped to get it flagged into oblivion.

Alright guys.. i'll admit, i dont get the joke. can any one explain? What's happening on that site and why do i see xml? (yes, i am still learning new stuff, like everyone else)

SOAP is a specification for exposing remote procedure calls via a web service. The client executes a SOAP request by making an HTTP Post request against a URL with an XML request body that specifies what remote procedure to call and what parameters to pass into it. The service, in turn, sends an HTTP response with an XML body that contains the return value from the procedure call.

SOAP services also usually include a WSDL, which is alternately said to stand for Web Service Definition List, Web Service Definition Language, or Web Service Description Language and is meant to define the methods and parameters available to the client.

Because the whole system is so complicated, cumbersome and over-engineered, the normal way to create a WSDL is to do it automatically using tooling. Unfortunately, different frameworks generate different and often mutually incompatible and non-interoperable WSDLs. So, for example, a .NET SOAP client might not be able to consume a WSDL generated by a Java framework.

The S in SOAP originally stood for "Simple", but the protocol is anything but.

Yes that comment really helps but if i am getting it right, it is something like JSON, right? like JSON is used in public API's and all sorts of server-client communication. Any particular reason to take SOAP against something like JSON?

Not exactly.

SOAP is a protocol specification for executing remote procedure calls over a network. SOAP uses XML for its message formatting and data serialization, and (usually) HTTP for its network protocol.

JSON, on the other hand, is a data serialization format rather than a remote procedure call format. It is sometimes used in web services - especially services based on Representational state transfer (REST) - to pass structured data between the client and server, but it is not a remote procedure call protocol in itself.

REST, in turn, is a method for designing a web service so that its functionality is accessed the same way that HTTP works. In REST, the service is organized into resources and methods, with resources corresponding to URLs and methods corresponding to the HTTP request methods: chiefly GET, POST, PUT and DELETE.

If you want to access a resource, you issue an HTTP GET request on the URL corresponding to that resource. If you want to create a resource, you issue an HTTP POST request on the URL corresponding to that resource with the data you want to post in the request body. If you want to update an existing resource, you issue an HTTP PUT request on the corresponding URL with the updated data. If you want to delete a resource, you issue an HTTP DELETE request on the corresponding URL.

Recently, many REST web services are designed to accept request data in JSON format and to send responses in JSON as well. Since web services are mainly consumed by client programs (rather than by humans browsing), JSON allows for a generic data structure that the client can consume and parse more easily than HTML, which is designed more specifically to structure documents.

Oh, i see, so it is some kind of communication protocol. But i am surprised i never heard of it even thought i have been writing/learning code for a few years now.

Finally a movement I can get behind!

Well in contrary to the SOPA people, the SOAP people aren't trying to forcibly push SOAP on all of us with laws and treaties. There's enough alternatives. Let them use SOAP :p

Unless you have to integrate with their "mission critical" SOAP based "enterprise solution".

I can't shake the association between your comment and the one calling to "please drop the soap"

Unfortunately I spent a couple years building web services tools in 2002,3. I have long since repented. Love the "S stands for Simple" link... fantastic dialog!

As someone who is about to work with a client's enterprisey SOAP API, I really wish I could upvote this article multiple times.

REST in peace, SOAP.

One does not simply get some REST.

There is a "REST in peace" joke there as well.

Have you considered Dr Bronner's? - http://www.drbronner.com/pdf/drbronner_32oz_Pep.pdf

Is there even 1 legit reason why someone would use SOAP over REST, aside from legacy?

This is great - put on some tweet/fb like/+1 buttons so we can help spread the word.

Almost thought it was SOPA.. misspelled article..:-P Agree.. SOAP is way to verbose....and annoying to read manually while debugging...

It helps if you click the article link and understand the content, before commenting.

lawl

Friends don't let friends do SOAP.

oh i see what you did there

*sorry, reddit is down

We should use SOPA againt SOAP and ask internet providers acroos the globe to block access to every server that runs a SOAP webservice.

..."Don worked with Microsoft and Dave Winer to create the original SOAP specification in 1998.":

http://www.microsoft.com/presspass/exec/de/Box/default.mspx

Actually, swell guy. I'm still wondering how he created such a mess.

I am not Barrack Obama, and I endorse this message.

So much efforts to stop law proposal X. Which is great.

What about the idea of a Open-USA or other Open-Iran where a true Meta-Democracy or whatever open society model is implemented where all efforts would be PRO something instead of hateful stuff like protesting.

This laws are proposed by lobbies that go against the interest of 99% of the persons. How is that even conceivable ?

All this big companies opposing could create a github project for open government and then elect a person that implements that.