2 ms·
Some of us are still building new products with XML RPC techniques. WSDLs and XSDs done right are a godsend for transmitting your API spec to someone. I use .N
by bob1029 2y ago
Some of us are still building new products with XML RPC techniques.
WSDLs and XSDs done right are a godsend for transmitting your API spec to someone. I use .NET and can call xsd.exe to generate classes from the files in a few seconds. It "just works" if both sides follow all of the rules.
The APIs I work with would be cartoonish if we didn't have these tools. We're talking 10 megabytes of generated sources. It is 100x faster to generate these types and then tunnel through their properties via intellisense than it is to read through any of these vendors' documentation.
- echelon 2y ago> WSDLs and XSDs done right are a godsend for transmitting your API spec to someone. I use .NET and can call xsd.exe to generate classes from the files in a few seconds. This sounds like protobuf and gRPC. Is that a close analogy?
- nsonha 2y agoThe latter would add subscription and streaming, and more efficient transports. But yeah they are basically the same idea. I hate that for years the concept of RPC was equated to XML which in turn equated to some implementation of the (XML based) tool and then a whole lot of distracting discourse around XML vs JSON, we kinda do still have that these days with yaml vs whatever.
- bob1029 2y agoIt's like those things, but I've never seen protobuf or gRPC used for APIs this extensive. The tooling around these paths is also lackluster by comparison if you're using something like Visual Studio. I'd rather fight XML namespaces and HTTP/1.1 transports than sort through the wreckage of what "best practices" has recently brought to bear - especially in terms of unattended complexity in large, legacy enterprises. Explaining to a small bank in Ohio that they're going to need to adjust all of their firewalls to accommodate some new protocols is a total nonstarter in my business.