4 ms·

> If the get-shit-done crowd wasn’t going to use SOAP, they still needed some standard way of doing things. Since everyone was using HTTP, and since everyone wo

> If the get-shit-done crowd wasn’t going to use SOAP, they still needed some standard way of doing things. Since everyone was using HTTP, and since everyone would keep using HTTP at least as a transport layer because of all the proxying and caching support, the simplest possible thing to do was just rely on HTTP’s existing semantics. So that’s what they did. They could have called their approach Fuck It, Overload HTTP (FIOH) Having been a developer during that period of history, I'd say OP gets it about right, that's what happened. For better or worse; it's not obvious to me that it was a poor choice. I do agree it somewhat misappropriated the "REST" term and misrepresented itself as being more "standardized" than it was -- also for more or less the reasons OP suggests: "that would have seemed recklessly blasé next to all the formal specification work that went into SOAP… a veneer of academic respectability". Although I do recall some people right from the start really were interested in HATEOAS and trying to do it... I think it's practical benefits were somewhat elusive. It reminds me of "semantic web" in some ways, not sure if that makes sense...

bsenftner 5y ago
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?
- 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.
throw_away 5y ago
I think not only was it a reaction against SOAP, but also against other common API styles like shoving everything into a GET query string or a POST body. Some name had to be attached to it. Simply 'HTTP' couldn't be used as both SOAP and query/POST both used HTTP as well (not to mention WebDAV). As a young engineer implementing an early, prominent 'REST' service, it was kind of a surprise to me to find these lurking, unused verbs like PUT or DELETE in the spec. But they were there & that style beat the living tar out of SOAP or query string. But, in my memory, rfc2616 was used far more as inspiration and reference than Fielding's dissertation.
indymike 5y ago
>For better or worse; it's not obvious to me that it was a poor choice. It wasn't a poor choice. It was the least common denominator, and what put it over the top was JSON instead of XML and using URLs for more than the address of the end point to send your RPC to. The problem with SOAP and other APIs of the era was everything was bespoke once you got past transport (and transport often was hard because different systems implemented transport differently). With REST, transport was settled, and at least the URL forced some kind of hierarchy, and you could reason that GET /user/settings would return a settings object for the user.
agentultra 5y ago
There were a couple of additional overlapping factors that contributed to the rise of the FIOH crowd and misinterpretation/misuse of REST and HATEOS: 1. the growing popularity of AJAX and SPA frameworks 2. the rapid growth in mobile clients We had to make a lot of trade-offs from ideal REST/HATEOS architectures to support these new clients. Eventually for some it wasn't enough. Facebook launched GraphQL in response to the problems with REST-based APIs they perceived for mobile clients. Fast forward to today and we're walking back to the RPC protocol era. The problem I have with this advice of, "choosing the right architecture for your application," is that it encourages an ecosystem of competing protocols. Exactly what made the prior RPC-era so annoying... not only was SOAP incredibly bloated and hard to deal with but every services that implemented it also implemented their own snowflake version of it with it's own errors and interpretations. Even if you had a "compliant" SOAP client it was likely that it would be incompatible with your service providers' service in some undocumented way. At least with FIOH-style APIs you just have to deal with their inane reasoning for return "200 OK: Error" responses and not implementing HATEOS.

bsenftner 5y ago

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?
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.

throw_away 5y ago

I think not only was it a reaction against SOAP, but also against other common API styles like shoving everything into a GET query string or a POST body. Some name had to be attached to it. Simply 'HTTP' couldn't be used as both SOAP and query/POST both used HTTP as well (not to mention WebDAV). As a young engineer implementing an early, prominent 'REST' service, it was kind of a surprise to me to find these lurking, unused verbs like PUT or DELETE in the spec. But they were there & that style beat the living tar out of SOAP or query string. But, in my memory, rfc2616 was used far more as inspiration and reference than Fielding's dissertation.

indymike 5y ago

>For better or worse; it's not obvious to me that it was a poor choice. It wasn't a poor choice. It was the least common denominator, and what put it over the top was JSON instead of XML and using URLs for more than the address of the end point to send your RPC to. The problem with SOAP and other APIs of the era was everything was bespoke once you got past transport (and transport often was hard because different systems implemented transport differently). With REST, transport was settled, and at least the URL forced some kind of hierarchy, and you could reason that GET /user/settings would return a settings object for the user.

agentultra 5y ago

There were a couple of additional overlapping factors that contributed to the rise of the FIOH crowd and misinterpretation/misuse of REST and HATEOS: 1. the growing popularity of AJAX and SPA frameworks 2. the rapid growth in mobile clients We had to make a lot of trade-offs from ideal REST/HATEOS architectures to support these new clients. Eventually for some it wasn't enough. Facebook launched GraphQL in response to the problems with REST-based APIs they perceived for mobile clients. Fast forward to today and we're walking back to the RPC protocol era. The problem I have with this advice of, "choosing the right architecture for your application," is that it encourages an ecosystem of competing protocols. Exactly what made the prior RPC-era so annoying... not only was SOAP incredibly bloated and hard to deal with but every services that implemented it also implemented their own snowflake version of it with it's own errors and interpretations. Even if you had a "compliant" SOAP client it was likely that it would be incompatible with your service providers' service in some undocumented way. At least with FIOH-style APIs you just have to deal with their inane reasoning for return "200 OK: Error" responses and not implementing HATEOS.