Letters about Soap (1997)

I have always assumed that for items which are shipped from Amazon fulfillment centers, if stolen or lost during shipment, Amazon is covering the cost not the vendor. But I don't know if that's actually true.

Sending the item back requires more effort than painting it. If you don't own a car (which is one of the main reasons you would order things like a tent for online delivery instead of going to your local outdoor/sporting/camping goods store where you could inspect them personally) then you need to somehow get a tent-sized and tent-massed box to the post office. (Remember, this isn't an ultralight-camping backpack tent; more a piece of yard furniture. It isn't necessarily portable.)

That's a huge problem. This situation is not something that requires "improvement". It's a well defined, easy to implement, no frills request. And which is particularly tried hard not to be delivered. Any of the parties which are to provide the solution do not use one modicum of brain to solve this. They ignore clear and concise communications and try to play dumb and by the book. Which was the all ask. “Don't play by the book, ignore this part which I particularly don't need“.

Which means that this can now play out with tablets instead of bars of soap.

Auto generated client code is nice in theory. In practice I find it only really useful as a starting point. There are enough choices to be made in writing even a simple HTTP api that its unlikely that a generic tool will generate useful code for a given application. This could include library usage (http client, serialization, logging, DI integration), async vs sync, logging requirements, tooling support for generated code. If you are in a language which has established std libraries and patterns this is less of a problem, but in something like Java that has evolved in all these areas over the years it can be a real problem.

Thrift and GRPC fill that niche nicely.

SOAP was OK in theory but many implementations left something to be desired. In particular I generally found it worked OK if the client code was autogenerated from the same SOAP implementation that the server used, but if you could not use that autogenerated code (such as when your client was using a language that the generator did not support) it was a lot more iffy.

I found a great book at Safari Books Online on SOAP that said that it was written because the author had been bitten by those issues and other things caused by some less than brilliant decisions on the part of those who made the SOAP standard (he was considerably less polite than I have phrased it) and wrote the book so the rest of us didn't have to waste as much time figuring it out as he had.

I don't remember the name of the book or the author, and when I needed a SOAP book a couple years after that it did not show up when I searched.

At one point I got tired enough of the quirks of making servers work with clients not using the server's client generator that I wrote a little proxy that would sit between the server and client. Then I'd write a client using the server's client generator that would just go through all my services and log the communications.

For example lets say I had a server to look up VAT, which takes a sales price and a country code and returns the VAT rate and the VAT amount.

I'd do that through the proxy two or three times, which would save the XML the client sent to the server and the XML response. I'd then compare the XML from the different client requests to see if anything changed, such as timestamps.

I'd then open the client XML in an editor, replace any timestamps with "___TIMESTAMP___", then search for the price and country code to see how those were stored. I'd replace them with "___PRICE___" and "___COUNTRY__".

For the XML from the server, I'd open that in an editor and search for VAT rate and amount. For those I'd figure out a regular expression that could find them.

Then on the client I could dispense with using a SOAP library. When I wanted to look up VAT I'd just use the normal HTTP library of the client language, using the edited client XML as a template. I'd use the normal string or regex client library to replace "___TIMESTAMP___", "___PRICE___", and "___COUNTRY___" with the correct values, send the XML to the server, then use the regex to pull the answers out of the response.

From there it was a simple matter to make a library to handle this. Input was the client XML template, URL of the server, and a list of name => value pairs, and a list of name => regex pairs. It would look for "___name___" in the template for each input name and replace it with its value, call the server, and then for each name in the second list, use the corresponding regex to find the result, and return a list of name => value pairs with those results.

It was a bit tedious. If someone deployed a new SOAP service I had to go generate a client using the same SOAP implementation the server used, call the new service from that through my proxy to get the XML for the templates, and then make a template and the extraction regexes, but it was still usually less hassle than mixing server and client SOAP implementations.

Why do you think RPC is a cleaner design than REST?

I think resource orientation works really well, most of the time.

Thanks to your comment, I was able to find a Snopes article:

https://www.snopes.com/fact-check/hotel-soap/

It stated that this story is a work of fiction. Funny story, though! (And another instance of “this is so easy to verify, it couldn’t possibly be false!” which I think I need to be more wary of).

I presume it means non profit.

"Welcome to the Soap-of-the-Week Club! Every week we'll send you some tiny bars of soap in a little stack. You may not revoke your membership."

And some of them have to be very moist.

If you create enough stacks around each other, that stops being a problem.

Yes.

Only tangentially related: does anyone else have the sense that GraphQL is fancy, modern SOAP?

I clicked on it expecting effusive praise of SOAP. Disappointed to find it's still only me, there must be tens of us who like it.

The S stands for Simple: http://harmful.cat-v.org/software/xml/soap/simple