4 ms·

I remember consulting for a tech company around '07 that needed to send remote (extremely high compute) tasks to a heavy iron server they dedicated to such work

I remember consulting for a tech company around '07 that needed to send remote (extremely high compute) tasks to a heavy iron server they dedicated to such work. They were using SOAP and having a very difficult time getting all the pieces and parts to work. At the time, Drupal 6 (a PHP web framework that used to be popular) had just released a "Services" module/plugin that enabled one to add a REST Service to any Drupal site. Working with them to initially understand what the SOAP tooling required, and then comparing that to what that REST Services Module required was a no brainer. They had a team of 11 people working on the SOAP infrastructure, and they were all super happy to ditch it and get back to their real work. Re-writing as a RESTful API using Drupal Services merely as a bureaucrat to communicate with their heavy iron server only required myself and one other programmer I brought with me. About 3 weeks later we completely replaced their SOAP infrastructure. For years afterwards, I'd check in on them and it just worked.

toyg 5y ago
The mistake of SOAP specs was to believe toolmakers were on their side, and tooling would magically solve all problems so that you would never actually have to look at what went down the wire. Whereas toolmaking companies were only on the side of making money, and looking down the wire was often unavoidable. REST went back to basics, simple protocols that humans could work on with little more than a text editor.
- jrochkind1 5y ago
  I mean, a tool-maker wants to sell you tools. Why wouldn't they want to sell you tools that obviated the need to look down the wire? If customers wanted those tools. Maybe it was just harder/more expensive to make those tools than the "just solve it with tools" spec-makers anticipated. Rather than it being any particular misalignment of incentives.
  - toyg 5y ago
    It's just that the cross-vendor interop efforts were often skin-deep. They all tried to lock you in one way or another, by implementing this or that spec draft a bit differently and making specs overly-verbose and burdensome to implement for anyone without a big budget. Microsoft had just won the browser wars that way, after all. But hey, if you stuck to one vendor, it all worked like magic.
    - jrochkind1 5y ago
      I see, the interoperability issue makes sense, and now I'm starting to remember it. (I never did THAT much with SOAP). But you really think the specs-writers (being some of the same people as the tool-makers?) intentionally made the specs overly-verbose and burdensome to implement, to protect their tools businesses? That's different from what you said in your original comment, about spec-makers "believing toolmakers were on their side" -- now you're saying the spec-makers were the tool-makers and not actually on the end-developer-user's side! I'm still inclined to believe a lot of it was people (both spec-makers and tool-makers) doing their best with a challenging problem, rather than intentionally sabotaging it for profit. But you think I'm too optimistic?
      - toyg 5y ago
        It really depends on your view of W3C as a standard body. > That's different from what you said in your original comment SOAP basically started as an attempt to learn from the mistakes of CORBA and RPC, and I think it started with good intentions all around. When complexity hit, however, the original designers basically went "we'll deal with it in the various sub-specs, but don't worry, tooling will take care of this anyway". I do think most of them were not malicious in this approach. Meanwhile, vendors understood where the wind was blowing, and got themselves heavily involved in the various efforts - hence the proliferation of WS-* and incompatibilities. > I'm still inclined to believe a lot of it was people (both spec-makers and tool-makers) doing their best with a challenging problem Considering the amount of money and manpower that went into these efforts, ascribing it all to lack of skills would possibly end up being less optimistic - about the state of corporations, the work they produce, and what this means for human progress. TBH I think the charitable reading is just that there were too many cooks in the WS kitchen. I feel some of them burnt pans on purpose, maybe they didn't, but at this point it doesn't matter much.
ldiracdelta 5y ago
Is there an analog here with the recent interest in graphql?
- deleted 5y ago
  [deleted]
- karmakaze 5y ago
  In what way? What is GraphQL competing with? I can't think of another reasonable alternative that allows the client to specify what they want in a single round trip. What preceded GraphQL was REST with a whole lot of inconsistent include_xyz query params.
  - ako 5y ago
    Odata
  - Zababa 5y ago
    > I can't think of another reasonable alternative that allows the client to specify what they want in a single round trip I don't know much about history so that might be a wild guess, but did people try to build SQL directly from the client and send it?
    - karmakaze 5y ago
      I'm also guessing, but I suspect that the sharp rise of mobile was a contributing factor. Mobile can have good throughput but not so good latency so packing more per request makes a lot of sense. At one place I worked we actually made two BFF (backend-for-frontend) servers that took one client request, made many within datacenter requests, put a single response together and sent it all back. We had one for mobile and one for web. We only had one datacenter region so made sense for global users regardless of throughput.
      - Zababa 5y ago
        That makes a lot of sense, thanks for sharing that.

toyg 5y ago

The mistake of SOAP specs was to believe toolmakers were on their side, and tooling would magically solve all problems so that you would never actually have to look at what went down the wire. Whereas toolmaking companies were only on the side of making money, and looking down the wire was often unavoidable. REST went back to basics, simple protocols that humans could work on with little more than a text editor.

jrochkind1 5y ago
I mean, a tool-maker wants to sell you tools. Why wouldn't they want to sell you tools that obviated the need to look down the wire? If customers wanted those tools. Maybe it was just harder/more expensive to make those tools than the "just solve it with tools" spec-makers anticipated. Rather than it being any particular misalignment of incentives.
- toyg 5y ago
  It's just that the cross-vendor interop efforts were often skin-deep. They all tried to lock you in one way or another, by implementing this or that spec draft a bit differently and making specs overly-verbose and burdensome to implement for anyone without a big budget. Microsoft had just won the browser wars that way, after all. But hey, if you stuck to one vendor, it all worked like magic.
  - jrochkind1 5y ago
    I see, the interoperability issue makes sense, and now I'm starting to remember it. (I never did THAT much with SOAP). But you really think the specs-writers (being some of the same people as the tool-makers?) intentionally made the specs overly-verbose and burdensome to implement, to protect their tools businesses? That's different from what you said in your original comment, about spec-makers "believing toolmakers were on their side" -- now you're saying the spec-makers were the tool-makers and not actually on the end-developer-user's side! I'm still inclined to believe a lot of it was people (both spec-makers and tool-makers) doing their best with a challenging problem, rather than intentionally sabotaging it for profit. But you think I'm too optimistic?
    - toyg 5y ago
      It really depends on your view of W3C as a standard body. > That's different from what you said in your original comment SOAP basically started as an attempt to learn from the mistakes of CORBA and RPC, and I think it started with good intentions all around. When complexity hit, however, the original designers basically went "we'll deal with it in the various sub-specs, but don't worry, tooling will take care of this anyway". I do think most of them were not malicious in this approach. Meanwhile, vendors understood where the wind was blowing, and got themselves heavily involved in the various efforts - hence the proliferation of WS-* and incompatibilities. > I'm still inclined to believe a lot of it was people (both spec-makers and tool-makers) doing their best with a challenging problem Considering the amount of money and manpower that went into these efforts, ascribing it all to lack of skills would possibly end up being less optimistic - about the state of corporations, the work they produce, and what this means for human progress. TBH I think the charitable reading is just that there were too many cooks in the WS kitchen. I feel some of them burnt pans on purpose, maybe they didn't, but at this point it doesn't matter much.

ldiracdelta 5y ago

Is there an analog here with the recent interest in graphql?

deleted 5y ago
[deleted]
karmakaze 5y ago
In what way? What is GraphQL competing with? I can't think of another reasonable alternative that allows the client to specify what they want in a single round trip. What preceded GraphQL was REST with a whole lot of inconsistent include_xyz query params.
- ako 5y ago
  Odata
- Zababa 5y ago
  > I can't think of another reasonable alternative that allows the client to specify what they want in a single round trip I don't know much about history so that might be a wild guess, but did people try to build SQL directly from the client and send it?
  - karmakaze 5y ago
    I'm also guessing, but I suspect that the sharp rise of mobile was a contributing factor. Mobile can have good throughput but not so good latency so packing more per request makes a lot of sense. At one place I worked we actually made two BFF (backend-for-frontend) servers that took one client request, made many within datacenter requests, put a single response together and sent it all back. We had one for mobile and one for web. We only had one datacenter region so made sense for global users regardless of throughput.
    - Zababa 5y ago
      That makes a lot of sense, thanks for sharing that.