5 ms·

Using SOAP APIs daily since over 15 years with .NET Framework development. Simple and easy to write and then easy to consume through Visual Studio generated cod

by m_st 5y ago

Using SOAP APIs daily since over 15 years with .NET Framework development. Simple and easy to write and then easy to consume through Visual Studio generated code. Tried some ObjC development early on the iPhone. Gave up quickly. I agree that SOAP looks like a mess. But given the right tools, it honestly just works. Never had a single issue with these APIs apart being stuck in .NET Framework land.

paulddraper 5y ago
And that's the issue. SOAP isn't some nice standardized language-agnostic API layer. SOAP is .NET/Visual Studio RPC. (Not technically, but in practice, due to its complexity.) And hey, great for you. But a lot of people want APIs to be broadly compatible.
- xienze 5y ago
  > SOAP isn't some nice standardized language-agnostic API layer. What? Of course it is (well, it's a messaging protocol). Where on earth did you get the idea that it's some Microsoft-only proprietary technology?
  - theamk 5y ago
    You missed the word "nice" in the GP's message. Also "(Not technically, but in practice, due to its complexity.)" No one says it is proprietary technology and yes, it is nominally standardized. It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology. So it seems that people who use MS ecosystem like SOAP ... while almost everyone else who tried it calls is over-complicated, incomprehensible and "worst dev experience of my whole career"
    - xienze 5y ago
      > It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology. Again, gotta call BS here. My early career was 100% SOAP and related WS-* technologies. And it was all in Java, Apache Axis and friends. Wildly popular at the time. Give it your WSDL, out pops a nice Java client. People didn’t like it not because it was difficult to use outside of the Microsoft ecosystem, they didn’t like it because it was the concepts were difficult to understand and there were many complicated technologies piggybacking off of it. It was hard to debug issues, Visual Studio or not. If you had to do something that a generated client could do, it was difficult, Visual Studio or not.
      - spookthesunset 5y ago
        Try calling a soap service with python. Oh boy enjoy the pain!
kgwxd 5y ago
Been using it daily myself for just as long with VS. Being basically exclusive to .Net is a huge set back. I would never make a new SOAP services these days. There are other solutions that just work with far less complexity, waste, and limitations.
k__ 5y ago
Yes, I had to use it in a Node.js project. Would imagine, with the right tooling and TypeScript it wouldn't have been that bad.
dolmen 5y ago
Looks like a case of Stockholm syndrom.
arethuza 5y ago
"it honestly just works" Which I would agree is most of the time - but then it doesn't and you have to try and work out what is going wrong from reams of impenetrable generated WSDL. Which is fun.

by m_st 5y ago

paulddraper 5y ago

And that's the issue. SOAP isn't some nice standardized language-agnostic API layer. SOAP is .NET/Visual Studio RPC. (Not technically, but in practice, due to its complexity.) And hey, great for you. But a lot of people want APIs to be broadly compatible.

xienze 5y ago
> SOAP isn't some nice standardized language-agnostic API layer. What? Of course it is (well, it's a messaging protocol). Where on earth did you get the idea that it's some Microsoft-only proprietary technology?
- theamk 5y ago
  You missed the word "nice" in the GP's message. Also "(Not technically, but in practice, due to its complexity.)" No one says it is proprietary technology and yes, it is nominally standardized. It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology. So it seems that people who use MS ecosystem like SOAP ... while almost everyone else who tried it calls is over-complicated, incomprehensible and "worst dev experience of my whole career"
  - xienze 5y ago
    > It is just so complex that it is impossible to use without heavy tooling support, and this tooling is only really usable in Microsoft's technology. Again, gotta call BS here. My early career was 100% SOAP and related WS-* technologies. And it was all in Java, Apache Axis and friends. Wildly popular at the time. Give it your WSDL, out pops a nice Java client. People didn’t like it not because it was difficult to use outside of the Microsoft ecosystem, they didn’t like it because it was the concepts were difficult to understand and there were many complicated technologies piggybacking off of it. It was hard to debug issues, Visual Studio or not. If you had to do something that a generated client could do, it was difficult, Visual Studio or not.
    - spookthesunset 5y ago
      Try calling a soap service with python. Oh boy enjoy the pain!

kgwxd 5y ago

Been using it daily myself for just as long with VS. Being basically exclusive to .Net is a huge set back. I would never make a new SOAP services these days. There are other solutions that just work with far less complexity, waste, and limitations.

k__ 5y ago

Yes, I had to use it in a Node.js project. Would imagine, with the right tooling and TypeScript it wouldn't have been that bad.

dolmen 5y ago

Looks like a case of Stockholm syndrom.

arethuza 5y ago

"it honestly just works" Which I would agree is most of the time - but then it doesn't and you have to try and work out what is going wrong from reams of impenetrable generated WSDL. Which is fun.