3 ms·

It's worth remembering how painful SOAP was, and what a disaster the early implementations were, and how little agreement there was on anything, for many years.

It's worth remembering how painful SOAP was, and what a disaster the early implementations were, and how little agreement there was on anything, for many years. Pete Lacey has written a hilarious satire of the whole thing: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it. I agree the term "microservices" has been ruined by those who came in with a very specific agenda. When I was at Timeout.com, in 2013, I used the phrase "an architecture of small apps": http://www.smashcompany.com/technology/an-architecture-of-small-apps http://www.smashcompany.com/technology/an-architecture-of-sm... It was a few months later, when Martin Fowler wrote his essay about it, that I first heard the term "microservices". When I read his essay, I assumed he was talking about the same thing that I was talking about. But I later found that the people promoting microservices defined it entirely in terms of HTTP, so I've gone back to talking about "an architecture of small apps" when I am talking about small apps that talk to each other with something other than HTTP, such as this kind of architecture: http://matthiasnehlsen.com/blog/2014/11/07/Building-Systems-in-Clojure-4/ http://matthiasnehlsen.com/blog/2014/11/07/Building-Systems-... In that example, Mattias Nehlsen builds a system where the communication is via Redis.

bitwize 9y ago
> Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it. Well, SOAP and Wiz-Dull. Many of the robotics platforms in common use (e.g., ROS) consist of independent, single-responsibility services that communicate over a shared message bus using a protocol that's not HTTP. But for enterprise apps, it's 2018. Other protocols? What other protocols? You should be using HTTP/2. It can MUX multiple streams over the same connection. FINALLY! At long last! We're no longer limited to a single concurrent stream!
nailer 9y ago
Sure, but you could point a generic client at a SOAP endpoint, and have a client for it, since the endpoint told the client what methods were available and what their signatures were. REST lost that. I think GraphQL has it back again. Any GraphQL people want to comment?
- onlyrealcuzzo 9y ago
  GraphQL Person. It does. But GraphQL is not a silver bullet. It adds a decent amount of complexity on the front end (assuming web / mobile app) that I don't think is worth it unless you're really making use of GraphQL's feature set.
  - nailer 8y ago
    Thanks. I feel the endpoint redundancy issues in REST APIs for what I'm doing now (and what I've worked on on the past) but there's so many other things that could deliver value I'm holding off on GraphQL till my next big project.
pjmlp 9y ago
I have spent the last couple of months enduring code generation from Swagger, boy do I miss WSDL tooling.

bitwize 9y ago

> Maybe SOAP wasn't the entirety of SOA, but back then it was a big part of it. Well, SOAP and Wiz-Dull. Many of the robotics platforms in common use (e.g., ROS) consist of independent, single-responsibility services that communicate over a shared message bus using a protocol that's not HTTP. But for enterprise apps, it's 2018. Other protocols? What other protocols? You should be using HTTP/2. It can MUX multiple streams over the same connection. FINALLY! At long last! We're no longer limited to a single concurrent stream!

nailer 9y ago

Sure, but you could point a generic client at a SOAP endpoint, and have a client for it, since the endpoint told the client what methods were available and what their signatures were. REST lost that. I think GraphQL has it back again. Any GraphQL people want to comment?

onlyrealcuzzo 9y ago
GraphQL Person. It does. But GraphQL is not a silver bullet. It adds a decent amount of complexity on the front end (assuming web / mobile app) that I don't think is worth it unless you're really making use of GraphQL's feature set.
- nailer 8y ago
  Thanks. I feel the endpoint redundancy issues in REST APIs for what I'm doing now (and what I've worked on on the past) but there's so many other things that could deliver value I'm holding off on GraphQL till my next big project.

pjmlp 9y ago

I have spent the last couple of months enduring code generation from Swagger, boy do I miss WSDL tooling.