Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST is the new SOAP

medium.com

Post reply on HN
Print view View original

111–120 of 351 posts

Re: REST is the new SOAP

#111

Post by Yokohiii »

ern wrote: post #93
speedplane wrote: post #27

Earlier quoted context omitted.

Programming Paradigm Becomes Popular B/C it gets stuff done --> left: it gets stuff done because it's smarter right: it's bad for you, it's actually getting less done middle: didn't read all that stuff, busy getting stuff done.

didn't read all that stuff, busy getting stuff done. I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-cultin…

Interesting viewpoint. But I am concerned that my mental capabilities can contain every brainfart that a misguided but smart person has.

Re: REST is the new SOAP

#112

Post by Dowwie »

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…

You're probably spending too much time reading tech blogs.

Re: REST is the new SOAP

#113

Post by sqldba »

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?

Re: REST is the new SOAP

#114

Post by unexistance »

peshooo wrote: post #75
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?

I use the stylish add-on for Firefox and remove the bars. https://userstyles.org/styles/browse?search_terms=medium.com

alternatively, use a bookmarklet to remove floating div... name the such as '1. rm float'

then, it's only alt-B -> 1 away, in Firefox

Re: REST is the new SOAP

#115

Post by nickjj »

pixie_ wrote: post #49
speedplane wrote: post #29

Earlier quoted context omitted.

If you're defining an RPC protocol in just a few minutes, you're leaving a ton of stuff out. Anyone that assumes an RPC call will successfully complete or assumes the network is always there, is writing buggy code. An "RPC protocol" makes writing such buggy code easier. A REST protocol makes it slightly harder. In theory, they are almost identical. But in practice, developers equate RPC calls with function calls, whi…

Too bad the first thing people do when consuming a REST API is to put a RPC wrapper around it (or find software that with auto-gen a wrapper for them) Subconsciously no one wants to deal with your carefully constructed REST URLs. They just want a function name and some parameters.

Yep, this is pretty much how it always goes.

A good example to me is Stripe.

I've written over 10 applications that use Stripe and every single time, the first thing I did was use Stripe's official library for the languages I work out.

Re: REST is the new SOAP

#116

Post by fapjacks »

therealmarv wrote: post #45

REST is freedom (with all its downsides when you can do what you want), SOAP is like military (with all its strong rules). It's like comparing a micro web framework with a full web framework. I think it always depends what you want to do in which scale with REST. What's great for a single hobby developer would be bad for a big world wide corporation. If you really want more rules, more restrictions and more boundarie…

This is really tangential, sorry, but I'd like to mention that the (US) military is strongly opinionated in a relatively small number of ways. Additionally, the rules are self-enforced throughout most of its structure, and almost none of the rules being broken will cause the system or its components to fail. The US military is actually incredibly flexible, because the (mostly) self-enforced strong opinions inform the decisions of subsets of the military all the way down to the individual level, allowing each component to be effective almost regardless of the health of the rest of the system. SOAP was incredibly inflexible. I think perhaps a better analogy would be to compare SOAP to some defense contractors, where things must work a certain way, or they grind to a halt and become very expensive to debug and triage. Also, incidentally, I'm interested to hear about your experiences with gRPC. I have just played with it, but it sounds like you had some issues scaling with it? Or didn't like it so much? I much prefer REST because of its inherent flexibility, as you do, but I am interested to hear from people who scaled with gRPC.

Re: REST is the new SOAP

#117

Post by borplk »

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…

This is consistent with my experience.

One element of it is also that in many cases the path to "becoming big" starts with bootstrapping and experimental projects that you may not know if it is going to survive and exist in a few years or if you are going to throw it away in 3 months.

So in those cases you may still choose to be scrappy, knowing that it will come back to bite you, but at that stage that is thought of the success scenario and a good problem to have (if it happens at all).

This is in contrast to large serious projects for large existing companies where you can much more confidently know that X and Y are going to be required because from day 1 you know the project is not just some casual thing.

This is also why I think the software creation process and tools need to seriously think about having adjustable safety/pain knobs to allow for cheap scrappy prototyping but also allow to tighten the screws for production.

You can kind of see a glimpse of this between various programming languages, particularly in their type system. But the general concept is broader than just that.

Re: REST is the new SOAP

#118

Post by borplk »

speedplane wrote: post #24

Lots of comments here arguing REST is popular because it's easy, but there's another higher level reason too: it forces you to think about the network. In far too many RPC protocols, calling functions that operate over a network are treated like normal functions. A function call, almost by definition, fails to take into account network errors, and race conditions where multiple events overlap. Network calls are not f…

The "force to think" part gets real old real fast though.

It's fine, people can understand "this function does network I/O so be careful".

Re: REST is the new SOAP

#119

Post by assafmo »

pixie_ wrote: post #41
assafmo wrote: post #23

Earlier quoted context omitted.

I agree. My main goal building an API is to make it easy to consume. Clients are lazy and impatient, and this is a good thing because it makes the developers work hard to make it easy to connect to their API.

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 copying an example to its browser address line. This is a simple use case, but I hope you get my meaning.

Re: REST is the new SOAP

#120

Post by IanCal »

speedplane wrote: post #68
IanCal wrote: post #56

Earlier quoted context omitted.

That means I can't use any kind of generic retry / back off code because I've now got to start dealing with your custom errors, and if you have html versions of the info Google will start demoting you. Just add a code, it's seconds of work.

You're assuming you want your API to work with a specialized crawler, like Google-bot. If that's important, then sure, design your API so Google-bot can crawl it nicely, but then it's Google designing your API, not you.

> You're assuming you want your API to work with a specialized crawler, like Google-bot.

Not really, I just don't

In general, the key point as about working in a generic way, given that it's so simple.

I don't like the idea of returning a human readable message that says there was an error but a machine readable message that says everything was fine. I have far too many cases of having to deal with human text explaining that a value is missing already in my data.

Post reply on HN