REST is the new SOAP • Hacker News Board

Re: REST is the new SOAP

#131

Post by jchw » Sat, Dec 16, 2017, 1:12 PM UTC

I'll be honest and say I refuse to read this based on its title. I've used SOAP somewhat recently. It's shittier than anything I've done in programming and I've done plenty of PHP 5 stuff. There's so much inane stuff in SOAP, and it's rare that a SOAP client in one language will work properly with a SOAP server in another.

Yes, it's HTTP-based APIs. But they've perverted the HTTP spec with weird extensions like SOAP attachments. So good luck doing SOAP operations by hand.

Not to mention it's insanely poorly specified. For example, SOAP requests can be GET or POST but most things only support using POST anyways. Why not specify it! God only knows.

I really hate SOAP a lot. Comparing it to REST for some Medium rant makes me irrationally angry.

Re: REST is the new SOAP

#132

Post by mannykannot » Sat, Dec 16, 2017, 1:18 PM UTC

mariocesar wrote: post #128

bbarn wrote: post #13

Why is REST so popular? Because it's easy to implement and works for lots of use cases. I'm sorry that you found places it doesn't, but in the real world, having been through that SOAP pain it's being compared to, I'd say there's not even a comparison. Everyone seems to want to find a reason to dislike product/technology/feature X but in this case, X is just better than anything we've had for a 90% adoption case. Wha…

Because there is no "booo" button. Every post in medium just have Likes or none, you can like or comment just that, making a critical comment is to much for most of the users that just want to say "I disagree" If medium has some kind of down vote, it will regulate itself a lot more, and users that disagree will not have to go to make a comment and expose themselves being critical. Right now is full of "Content Hacker…

So long as an article makes a reasonable attempt to present a viewpoint, downvoting does not add anything to the issue. If you disagree, upvote those replies that you agree with (unfortunately, Medium makes that more complicated than is should be.) If no-one can be bothered to say what's wrong with the article, maybe there isn't much wrong with it.

For example, xmlrpc has been recommended in comments as alternatives to consider. Maybe what's wrong with Medium is that the informative replies are on HN... (to be fair, grpc is mentioned on Medium.)

Re: REST is the new SOAP

#133

Post by pagutierrezn » Sat, Dec 16, 2017, 1:20 PM UTC

jchw wrote: post #131

I'll be honest and say I refuse to read this based on its title. I've used SOAP somewhat recently. It's shittier than anything I've done in programming and I've done plenty of PHP 5 stuff. There's so much inane stuff in SOAP, and it's rare that a SOAP client in one language will work properly with a SOAP server in another. Yes, it's HTTP-based APIs. But they've perverted the HTTP spec with weird extensions like SOAP…

You should read it. The title is misleading. I think the author proposes that REST is the new (failed) SOAP.

Re: REST is the new SOAP

#134

Post by andybak » Sat, Dec 16, 2017, 1:22 PM UTC

adrianmsmith wrote: post #37

I think there’s a tendency in software for people to start out without understanding all the complexities they’re going to encounter. I think this is just human nature. When you start out doing RPC you think, I don’t want to bother with schemas, I don’t want to bother with hierarchical error codes, I don’t foresee the need to set the user’s password but not retrieve it. So you don’t want to bother with a technology w…

I think this is best labelled a meta-Greenspun:

> "Any sufficiently complicated X contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Y." (where X is the new "simple" way and Y is whatever the greybeards are using.

Re: REST is the new SOAP

#135

Post by DarkCrusader2 » Sat, Dec 16, 2017, 1:26 PM UTC

jimnotgym wrote: post #96

DarkCrusader2 wrote: post #25

Earlier quoted context omitted.

I avoid medium posts as much as possible. Everyone is an expert on there with very strong opinions telling me how every technology older than 2 years and not written in javascript is obsolete/dead/not the right way/new . And what's with the UI on their publications. They take up top 25% of the screen with the branding and navbar and bottom 10% asking me to sign in and both sticks on the screen. Who approved that?

Firefox reading view could have been invented for Medium! It doesn't make the articles any better though. Personally I will keep using REST. If I ever find something is too CPU or network hungry with http/JSON I will take a look at a binary protocol. For me REST has opened up the world of web applications to simple integrations. It is what makes simple, single use case web apps useful.

Exactly. It doesn't have to be one or the other. Why can't they both be suitable for different use cases.

Re: REST is the new SOAP

#136

Post by mannykannot » Sat, Dec 16, 2017, 1:31 PM UTC

bthornbury wrote: post #52

adrianmsmith wrote: post #37

I think there’s a tendency in software for people to start out without understanding all the complexities they’re going to encounter. I think this is just human nature. When you start out doing RPC you think, I don’t want to bother with schemas, I don’t want to bother with hierarchical error codes, I don’t foresee the need to set the user’s password but not retrieve it. So you don’t want to bother with a technology w…

You're right of course, like the first time you hit a race condition (with a week of debugging) and build a distributed lock system. You publish it and people find it useful! Only to realize later postgres offers fine locking capabilities far beyond what you've created (now that you get it). Then you realize that all anybody is doing is creating subsets of Erlang (half serious). So why aren't we all using that? In th…

Unfortunately, we get a whole lot of ad-hoc, informally-specified, bug-ridden, slow reinventions of the wheel for every better mousetrap. Usually (though not always) the best simple solutions come from those who understand where the complexity lies.

Re: REST is the new SOAP

#137

Post by gregman1 » Sat, Dec 16, 2017, 1:32 PM UTC

I think Swagger (OpenAPI) is the new SOAP.

Re: REST is the new SOAP

#138

Post by 11235813213455 » Sat, Dec 16, 2017, 1:40 PM UTC

and GraphQL is the new REST

Re: REST is the new SOAP

#139

Post by jdbernard » Sat, Dec 16, 2017, 1:41 PM UTC

sqldba wrote: post #113

zargath wrote: post #81

Comparing REST to SOAP, is to me like comparing HTML to SASS/LESS. SOAP had so many flaws, no need to repeat. But the fact that you could not trust that SOAP software created using Microsoft software would work with something created with Java software was a disaster. Sometimes I ended up building custom SOAP libraries to connect with the other services. It was promised to solve all our problems, but ended up creatin…

Why did SOAP not work between MS and Java?

SOAP is a very complicated spec, and intended to be used to automatically generate bindings in whatever language you're using base in the service definition fine (WSDL). It's not intended to be human-readable.

So to provide a SOAP framework you need to not only provide all the plumbing for dealing with the actual messages, but all the rolling to auto-generate the client library for an API. The whole mechanism is very complex and there were lots of places where the spec was not specific enough, or the implementations had slightly different opinions about interpretation.

Then on top of that, Microsoft for a good while purposefully deviated from the spec to provide "enhancements" that other implementations had to reverse engineer to be compatible.

Then on to of that you had a whole raft of extensions to the spec like WS-Security, WS-Reliability, and (ironically for a "standard") WS-Interoperability. The chances that all of those specific extensions worked across different implementations was even more remote.

So, there were two big reasons in my opinion, that SOAP failed and REST shined:

1. The only way you could really trust that your SOAP client would generate compatible bindings for an API is if you wrote the API. This defeats the purpose of having public APIs. The author's complaint about REST implementation taking hours when his known tools take minutes rings hollow to me because I've spent weeks trying to get two simple SOAP systems communicating.

2. SOAP reinvents the wheel in a much more complicated fashion. Mant of those WS-* extensions were written to provide things that you already get if you embrace the existing networking stack (TCP/IP, HTTP, etc.). SOAP was trying to be transport-agnostic, so it ignored the existing stack and had to reinvent most of it itself. One of the key principles of REST is to embrace HTTP and let the existing system do with for you.

For example, SOAP used POST requests for everything. So all the tools that work with HTTP requests on the wire have to be rewritten to understand SOAP semantics instead of just looking at the request method.

Most of the use-cases in practice of WS-Security is covered by TLS/SSL. Theoretically WS-Security provides more flexibility, and can handle use-cases that TLS/SSL can't, but in practice it leads to over-complicated and less-secure systems.

WS-Reliability exists because you might use SOAP over something that isn't TCP. Most of the guarantees WS-Reliability gives you could have gotten for free if you entrance TCP.

Re: REST is the new SOAP

#140

Post by zo1 » Sat, Dec 16, 2017, 1:43 PM UTC

assafmo wrote: post #119

pixie_ wrote: post #41

Earlier quoted context omitted.

Are you assuming REST is easier than RPC to develop and/or consume? After moving to a REST based API there were endless meetings between co-workers of what is and isn't a good REST url. Our clients often come to us with dumb mistakes. Unlike RPC where the parameters go in a single place. With REST the parameters are spread across the verb, url, header, query param, etc..

Yes, I'm assuming REST is easier because of tools like curl, postman and even the major browsers with HTTP GET and great dev tools. With RPC your consumers probably need to know some coding and even maybe a specific language, a framework or a library. So yes, for me REST is easier, and I always love to see landing pages like this one - https://freegeoip.net - where the client can test the API in a few seconds by copy…

I don't really understand the debate here regarding tooling. REST, SOAP and RPC are all ways to define/codify the API and the parameters. It all goes over HTTP at the end. So Curl, postman and all other HTTP-enabling tools/libraries can be used.

SOAP even has handy discovery tools that frameworks can consume and construct entire APIs in most popular languages.

It's just that no-one uses SOAP from a browser because XML is a royal PITA to write in JS. I would assume it's because all JS developers are too-busy writing more libraries-for and layers-over JSON.