REST is the new SOAP • Hacker News Board

Re: REST is the new SOAP

#81

Post by zargath » Sat, Dec 16, 2017, 10:26 AM UTC

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 creating more.

REST is not a "standard" library, it is just a basic guideline on how to use the HTTP protocol "out of the box".

What the author seems to be looking for, is one hammer to fix all problems.

If you are spending too much time writing REST services, maybe your frameworks are flawed, you could be automating more or your interface is too complex?

Re: REST is the new SOAP

#82

Post by hkon » Sat, Dec 16, 2017, 10:28 AM 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…

Yes, and it is this lack of understanding which ironically enough pushes technology forward. One RPC implementation after another.

Re: REST is the new SOAP

#83

Post by amq » Sat, Dec 16, 2017, 10:29 AM UTC

matttproud wrote: post #77

XMLRPC with WSDL was bad enough that I only had to use it once. We migrated WSDL stack to REST (2007-8), which was an improvement, but it was fraught with a fat clients for each language integration to uniformly handle SSO authorization and other sundries. Has the author considered something built upon Protocol Buffers, which have can have reasonable versioning semantics and is portable and supports status code canon…

What was wrong with WSDL? I also only used it just once or so, but found it to be transparent. Generated a client (set of functions) for two languages and never touched the WSDL or SOAP directly afterwards.

Re: REST is the new SOAP

#84

Post by lfischer » Sat, Dec 16, 2017, 10:30 AM UTC

felipelemos wrote: post #38

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…

And REST is easier to debug. This make a huge difference when you have a big and complex system.

How exactly do you think REST is easier to debug and what alternatives are you comparing it to?

Re: REST is the new SOAP

#85

Post by speedplane » Sat, Dec 16, 2017, 10:30 AM UTC

magic_quotes wrote: post #79

speedplane wrote: post #36

Earlier quoted context omitted.

Don't agree at all. There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')". The former feels like a function call, and callers will assume it operates like one. However, in reality the former is not a function, it's making a network call, and it's incredibly unreliable. In theory, the latter does the same thing, but it's far more…

> There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')". Is it really a useful distinction? Let's rename our 'foo()' to 'dangerously_unreliable_with_unpredictable_latency_foo()'. Is there still a huge difference? > accordingly that it may fail. Developers will be more inclined to plan for errors when the possibility of such erro…

Dangerous and unreliable don't really capture it... how about potentialy_async_call_relying_on_network_that_raises_lots_of_exceptions_foo(), then I'd agree they are pretty similar. However http.get("foo") often says the same thing more succinctly.

And to your second point... yes, all developers should check possible exceptions, just like all children should brush their teeth. However, if you have bad habits and you aren't good all the time, then at lease brush your teeth after eating sweets, and likewise, developers should please check for exceptions around network calls.

Re: REST is the new SOAP

#86

Post by einrealist » Sat, Dec 16, 2017, 10:32 AM UTC

HTTP is just a way to communicate state - a protocol that _can_ be used for implementing the architectural style. Unfortunately, most of the rant is about HTTP.

Once you see HTTP just as one example of a more abstract way to interact in a client-server model, your focus will shift towards the more important topic: semantic formats that represent state, formats that make it easy to write clients against. And if you do it right, you build a vocabulary that represents your domains. A good format to start with is JSON-LD. But please don't just describe the entities of your business domain. You have to describe semantics of how the client can interact with the server and change state (like links, actions, feeds). And if you build a business around it, put these semantics / vocabularies at a central place - build something like https://schema.org for your own corporation.

Then use HTTP for communication and building out your systems. And it will be more robust, flexible and scalable than anything built on SOAP.

Re: REST is the new SOAP

#87

Post by k__ » Sat, Dec 16, 2017, 10:32 AM UTC

I did REST for years and now people are all about CQRS/ES.

"Make CRUD with REST, keep it simple!"

"No app is CRUD, it's an illusion! Model your events all the way!"

Well, guess the pendulum will someday stay somewhere in the middle?

Re: REST is the new SOAP

#88

Post by kiallmacinnes » Sat, Dec 16, 2017, 10:33 AM UTC

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.

I think you missed his primary point. By doing what you describe above, generic client side code to handle retries/backoff etc etc is rendered useless. Your users now have to implement something custom for this (and, if your doing network operations and DONT do this, you likely don't have a very robust system).

Re: REST is the new SOAP

#89

Post by lfischer » Sat, Dec 16, 2017, 10:34 AM UTC

speedplane wrote: post #36

magic_quotes wrote: post #32

Earlier quoted context omitted.

The proper REST API should be specified as the set of domain-specific document formats (media-types) and have a custom browser as a client. Turns out, we already have HTML and web-browsers, so there is little point in actually building such APIs. It's always more appropriate to build a website instead. On other hand, what usually called 'REST' is nothing else but RPC where 'procedure call' = 'http method + url'. Ther…

Don't agree at all. There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')". The former feels like a function call, and callers will assume it operates like one. However, in reality the former is not a function, it's making a network call, and it's incredibly unreliable. In theory, the latter does the same thing, but it's far more…

Some time ago, another HN user commented a lack of good async support in languages and libraries caused some of the issues with early RPC. With more languages introducing futures and promises as return values or asyncronous functions, don’t you think we might finally have the tools to express that unreliability in a simple function call?

Re: REST is the new SOAP

#90

Post by dgelks » Sat, Dec 16, 2017, 10:35 AM UTC

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

Thanks for this - Stylish add-on for chrome also works nicely too!