4 ms·

I will say that the core idea of SOAP/WCF services is honestly pretty sound. There is no sensible reason (imo, anyway) that everyone needs to be using stringly

I will say that the core idea of SOAP/WCF services is honestly pretty sound. There is no sensible reason (imo, anyway) that everyone needs to be using stringly-typed data and manually parsing REST responses when the underlying code all has type definitions. I get that it came with headaches (and I suppose people wanted to work in untyped languages) but jettisoning the entire idea of generating the client feels like it was throwing out the baby with the bathwater.

edejong 3y ago
But you know what happened to SOAP? It was smothered by its own success. The allure of interoperability and extensibility attracted everyone and their cat to the party. With so many stakeholders involved, it became a classic case of "too much design by committee." It's like trying to paint a masterpiece by having a thousand artists contribute strokes—chaos ensues. And let's not forget the influx of junior developers during that time. I mean, we can't blame them entirely, can we? SOAP standards were complex and enormous. It's no wonder they struggled to grasp the underlying paradigms. We had an army of fresh faces flooding the scene, and the sheer complexity overwhelmed them. So, SOAP ended up being the baby tossed out with the bathwater. It had its merits, but the challenges it faced were just too much to bear. Still, it's worth reflecting on its strengths and the lessons we can learn. Maybe someday we'll find a way to strike a balance between the elegant core idea and the practical realities of implementation.
- emodendroket 3y ago
  It's not like people don't find a way to screw up REST semantics and make that complicated anyway.
  - edejong 3y ago
    Absolutely. The lasting ideas are KISS and Occam's Razor.
    - emodendroket 3y ago
      Sure but there's such a thing as too simple. It is distressing to think of the number of manhours wasted on each and every application using JSON having to have its own standard for handling dates since that was one of those things too complicated for the spec to have an opinion about.
      - edejong 3y ago
        I totally agree. JSON at the application level is too simple of an abstraction, leading to unnecessary complexity.
- Faint 3y ago
  It ended up being so complex, that none of the implementations were up to spec, and hardly any 2 implementations talked to each other out of the box. i.e. the exact opposite it was meant to do.
  - VaxWithSex 3y ago
    can confirm
- easton 3y ago
  We are pretty much right back where we started with OpenAPI. You can generate a client (or a server) from this YAML file that a lot of frameworks can generate for you from your code, and the file also describes the types. I wouldn't say it is much simpler though, the schemas can get super complicated (as can configuring the darn API Gateway people inevitably think is necessary).

edejong 3y ago

But you know what happened to SOAP? It was smothered by its own success. The allure of interoperability and extensibility attracted everyone and their cat to the party. With so many stakeholders involved, it became a classic case of "too much design by committee." It's like trying to paint a masterpiece by having a thousand artists contribute strokes—chaos ensues. And let's not forget the influx of junior developers during that time. I mean, we can't blame them entirely, can we? SOAP standards were complex and enormous. It's no wonder they struggled to grasp the underlying paradigms. We had an army of fresh faces flooding the scene, and the sheer complexity overwhelmed them. So, SOAP ended up being the baby tossed out with the bathwater. It had its merits, but the challenges it faced were just too much to bear. Still, it's worth reflecting on its strengths and the lessons we can learn. Maybe someday we'll find a way to strike a balance between the elegant core idea and the practical realities of implementation.

emodendroket 3y ago
It's not like people don't find a way to screw up REST semantics and make that complicated anyway.
- edejong 3y ago
  Absolutely. The lasting ideas are KISS and Occam's Razor.
  - emodendroket 3y ago
    Sure but there's such a thing as too simple. It is distressing to think of the number of manhours wasted on each and every application using JSON having to have its own standard for handling dates since that was one of those things too complicated for the spec to have an opinion about.
    - edejong 3y ago
      I totally agree. JSON at the application level is too simple of an abstraction, leading to unnecessary complexity.
Faint 3y ago
It ended up being so complex, that none of the implementations were up to spec, and hardly any 2 implementations talked to each other out of the box. i.e. the exact opposite it was meant to do.
- VaxWithSex 3y ago
  can confirm
easton 3y ago
We are pretty much right back where we started with OpenAPI. You can generate a client (or a server) from this YAML file that a lot of frameworks can generate for you from your code, and the file also describes the types. I wouldn't say it is much simpler though, the schemas can get super complicated (as can configuring the darn API Gateway people inevitably think is necessary).