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

291–300 of 351 posts

Re: REST is the new SOAP

#291

Post by qznc »

jstimpfle wrote: post #266
qznc wrote: post #44

Yet another discussion where people talk past each other because everybody means different things by "REST". It certainly is not the "REpresentational State Transfer" as invented originally.

Now why does everybody mean different things by "REST"? Maybe because the idea "REpresentational State Transfer" was never that clear from the start. So that's some common ground. It's a bad idea.

It is hard to evaluate an idea without being tied to an implementation. How would you evaluate Monads as an idea without talking about Haskell?

The primary problem with REST is that most people learn it by example. Then they believe it is about web services returning JSON or about pretty URLs. It is not.

Re: REST is the new SOAP

#292

Post by jstimpfle »

digi_owl wrote: post #187
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…

I worry that this is something that can be applied to programming in general these days. Back in the day of the C64 etc, programmers had to worry about the underlying hardware as they were for the most part working with assembly. But as increasingly abstract languages have come to be (most modern ones use virtual machines and garbage collectors), the programmer never have to consider the hardware their code has to in…

I don't think you closely read what parent wrote. Do you think a function call is "too abstract" because "nobody knows what it's doing under the hood"?

Re: REST is the new SOAP

#293

Post by BillinghamJ »

kapad wrote: post #166

I read the article upto the point where they consider using rest to create an entry into the rest_password_email table or some such thing. That's stupid and ludicrous. That isn't even a use case for REST. I think the writer needs to consider taht http APIs cover many different use cases with subtle differences. REST exists to solve the problem for one of those use cases, i.e. data model interactions over HTTP. But HT…

RPC is a concept - not a protocol.

For instance, the implementation of RPC I use looks like:

    POST /v1/:method
A JSON object in the request body is the only parameter on the method. The response body is the returned value encoded as JSON.

Very simple, and still entirely within HTTP. Just not RESTful.

Re: REST is the new SOAP

#294

Post by olavk »

jstimpfle wrote: post #264
olavk wrote: post #129

We developers need to understand there are no one-size fits all solutions. No protocol is optimal for all use-cases. Design is always a question of trade offs. Architectures are means to an end . The OP's story is a bit weird, because it seems they had a system which worked very well with XML-RPC, but they changed it to REST for no apparent reason except that "REST is the future". Regardless of the merits of REST vs…

Sorry, but these kinds of excuses always remind me of homeopathy zealots explaining why there technology didn't work in this case. REST, just like OOP, is not a means to an end. It's fundamentally wrong. It's trying to shoehorn strange philosophical viewpoints into what's a technical problem. It's trying to decompose problems that can't be decomposed. It's... never the right solution. I've never seen it succeed. Like…

Are you saying OOP never have value?

Re: REST is the new SOAP

#295

Post by jstimpfle »

speedplane wrote: post #66
IanCal wrote: post #51

Earlier quoted context omitted.

I don't see how those things are really solved with rest, particularly given that people will often be using a wrapper rather than building their URLs manually everywhere.

Definitely not "solved", just made more explicit, kind of like a warning sign in the road. A while ago I worked with an RPC system where the RPC calls looked just like normal function calls... everything worked well, until it didn't. Anytime a computer program consumes a potentially scarce resource (e.g., network, disk, database, etc), there should be some warning-sign or flag raised to the developer. RPC hides that,…

Or in other words, there is absolutely no technical justification for using this overly verbose and unmaintainable mess. It's just some vague philosophical thing that has no clear benefits. Like OOP.

Re: REST is the new SOAP

#296

Post by jstimpfle »

olavk wrote: post #294
jstimpfle wrote: post #264

Earlier quoted context omitted.

Sorry, but these kinds of excuses always remind me of homeopathy zealots explaining why there technology didn't work in this case. REST, just like OOP, is not a means to an end. It's fundamentally wrong. It's trying to shoehorn strange philosophical viewpoints into what's a technical problem. It's trying to decompose problems that can't be decomposed. It's... never the right solution. I've never seen it succeed. Like…

Are you saying OOP never have value?

Yes.

Well, the exception perhaps being that its object-verb syntax supports function name completion in IDEs better. But I think it's a net negative, since it has more negative effects on architecture (wrong structure, because developers are encouraged to invent vague concepts to be home to methods that do less and less. It leads to endless bikeshedding).

Not to speak of other bad ideas that once defined what OOP was, and are now commonly seen as wrong - like inheritance or even multiple inheritance.

Re: REST is the new SOAP

#297

Post by pjmlp »

wobbleblob wrote: post #55

It turns out that schema-first design is useful. It turns out that having a cross-platform industry standard for such schemas is useful. What developers didn't like about SOAP aren't necessarily the features, it's all the XML.

XML is great, allows lots of tools to be used.

Re: REST is the new SOAP

#298

Post by olavk »

jstimpfle wrote: post #296
olavk wrote: post #294

Earlier quoted context omitted.

Are you saying OOP never have value?

Yes. Well, the exception perhaps being that its object-verb syntax supports function name completion in IDEs better. But I think it's a net negative, since it has more negative effects on architecture (wrong structure, because developers are encouraged to invent vague concepts to be home to methods that do less and less. It leads to endless bikeshedding). Not to speak of other bad ideas that once defined what OOP was…

And you have never seen an OOP project succeed?

Re: REST is the new SOAP

#299

Post by dsego »

tie_ wrote: post #258
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…

> ...having been through that SOAP pain it's being compared to, I'd say there's not even a comparison OK, that is indeed the most usual response to "Why REST?". The main reason why people like REST is "because SOAP". It's a false dichotomy that the industry has fallen for. Oh, yeah, and you can run the GETs directly in your browser/cURL. I like that part too, but it only gives you so much. REST is more of a philosoph…

It's an architectural style.

Re: REST is the new SOAP

#300

Post by IanCal »

speedplane wrote: post #66
IanCal wrote: post #51

Earlier quoted context omitted.

I don't see how those things are really solved with rest, particularly given that people will often be using a wrapper rather than building their URLs manually everywhere.

Definitely not "solved", just made more explicit, kind of like a warning sign in the road. A while ago I worked with an RPC system where the RPC calls looked just like normal function calls... everything worked well, until it didn't. Anytime a computer program consumes a potentially scarce resource (e.g., network, disk, database, etc), there should be some warning-sign or flag raised to the developer. RPC hides that,…

I'm not really sure I see the difference. One of the first things done is to wrap all the calls to the webservice in some kind of API (often using a pre-existing library), which puts you back exactly where you were with calling a function which happens to make a web request.
Post reply on HN