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

341–350 of 351 posts

Re: REST is the new SOAP

#341

Post by aaimnr »

jstimpfle wrote: post #301
olavk wrote: post #298

Earlier quoted context omitted.

And you have never seen an OOP project succeed?

I've seen quite a few good projects written in an "OOP" language, but not in an OOP style - mostly misuse classes for namespacing (which I don't think is a good idea either since it makes usages of namespaced things hard to find). I've never seen a "true" OOP project that wasn't quite a mess and couldn't have been written much cleaner in a plain old procedural style: Use freestanding functions, the most successful ab…

Most of the things you mention are considered anti-patterns in OOD nowadays anyway:

- singletons

- getters/setters everywhere (but not in favour of public fields, which just as much introduce tight coupling, but 'tell don't ask' style which allow to localise functionalities prone to change)

- introducing interfaces upfront - it goes against Reused Abstraction Principle or Rule of Three (discover rather than design abstractions, apply interface only when you have at least 3 classes that would adhere to it)

Both OOD and functional programming try to reach loose coupling and composability by different means. All these 'patterns' have usually some more sane general architectural concern standing behind. It would be interesting to know whether old school procedural approach allows you to achieve all those architectural benefits in large scale applications.

Re: REST is the new SOAP

#342

Post by RandyRanderson »

pixie_ wrote: post #8

I agree 100% with this article. A simple RPC API spec takes minutes to define. 'Rest'ifying takes much longer, there are a million little gotchas, no real standard. Everyone has a different opinion of how it should be done. Data is spread across verbs, urls, query params, headers, and payloads. Everyone thinks everyone else doesn't 'get' REST. If you try to suggest something other than REST in the office you become t…

"cargo cult of pointlessness": that is hilarious!

Re: REST is the new SOAP

#343

Post by tatersolid »

pjmlp wrote: post #337
tatersolid wrote: post #332

Earlier quoted context omitted.

Ahh, to be young and naive. Decades of horrific developer pain disagree with you. The “tools@ all have different ideas of what is correct, good style, the right name spacing and encodings...

I have been coding since the mid-80's. Feels refreshing to be called young. Just this week I was having the pleasure of using XSD schema validation to ensure files aren't corrupted.

We’re about the same age. How is it that you’ve not experienced the same horrible almost-but-not-quite interoperability messes with XML and SOAP that I have over the last 20 years?

Do you love ASN.1 as well?

Re: REST is the new SOAP

#345

Post by he0001 »

he0001 wrote: post #344

Why does soap or rest matter? None solve the problem of the need of communicating with a predefined protocol.

As an industry I do think we are extremely fast of ditching old lessons learned in favor for the new shiny, which still gives the same ol’ problems. We like to redress the same problems in different coats but still have the same problems at hand. We think the “new shiny” is solving the problems, just because there’s yet no structure highlighting the problem. And therefore it’s “nice”, but it will eventually creep up on you. Also if you had a bad experience with tech X you will hate it, and disregard everything else it actually solves and does it good.

Re: REST is the new SOAP

#347

Post by paulddraper »

osrec wrote: post #216
paulddraper wrote: post #176

Earlier quoted context omitted.

HTTP caching behavior is extremely flexible. You could use must-revalidate with ETag or If-Modified-Since caching.

True, but the whole process becomes a bit convoluted. I feel it's easier to just stay away from HTTP caching where possible.

It's always possible.

It's just not always performant.

Re: REST is the new SOAP

#348

Post by speedplane »

badsectoracula wrote: post #308
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…

How is that different than any function call that start something in the background? I have used and even written myself simple job code (with threading) that has functions like (simplified): int start(void (*job)(void*), void (*done)(void*), void* tag); `job` is called on a separate thread at some point (goes through a job scheduler) and once it is done, `done` is called at the "main" thread (at some synchronization…

The main difference is that networks are inherently unreliable. Threaded or multi-processed applications can also be unreliable but for different reasons.

The goal should be to inform the caller of the types of errors that may pop up. Obviously, with network or RPC calls, the caller should handle the case where the network is down. With threaded apps, the potential errors are more subtle, but the caller should definitely be aware that it's not a synchronous call. The function header you proposed is a bit clumsy due to the c semantics, but gets the general point across well enough.

Re: REST is the new SOAP

#349

Post by speedplane »

jstimpfle wrote: post #295
speedplane wrote: post #66

Earlier quoted context omitted.

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.

Do you consider clarity, maintainability, and readability a "philosophical thing" or a "technical" one?

Re: REST is the new SOAP

#350

Post by speedplane »

LaGrange wrote: post #143
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.

me: already groaning at the thought of fixing stuff after that one who didn't "read all that stuff," the "left", and thankfully the right was too busy pontificating to do anything so there's no fixing to be done. Read. The. Damn. Stuff.

Much easier to fix other people's code if they never got the chance to write it in the first place.
Post reply on HN