5 ms·

Not a year goes by where I’m not convinced that things would be easier if as a community we used a modern version of the soap protocol, maybe with JSON instead

by zwkrt 4y ago

Not a year goes by where I’m not convinced that things would be easier if as a community we used a modern version of the soap protocol, maybe with JSON instead of XML. RPC is such a clean design compared to REST, and it we had auto-generated client code 15 years ago, something the likes of swagger are still catching up with.

Deadron 4y ago
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.
- charles_kaw 4y ago
  Thrift seems to have a really nice solution of providing only types that eventually break down into scalars. And only for exchanging data - it doesn't dare prescribe the rest of that. I liked working with it.
brianm 4y ago
Thrift and GRPC fill that niche nicely.
tzs 4y ago
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.
ahepp 4y ago
Why do you think RPC is a cleaner design than REST? I think resource orientation works really well, most of the time.

by zwkrt 4y ago

Deadron 4y ago

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.

charles_kaw 4y ago
Thrift seems to have a really nice solution of providing only types that eventually break down into scalars. And only for exchanging data - it doesn't dare prescribe the rest of that. I liked working with it.

brianm 4y ago

Thrift and GRPC fill that niche nicely.

tzs 4y ago

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.

ahepp 4y ago

Why do you think RPC is a cleaner design than REST? I think resource orientation works really well, most of the time.