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

251–260 of 351 posts

Re: REST is the new SOAP

#251

Post by pixie_ »

ThrowawayR2 wrote: post #195
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…

> If you try to suggest something other than REST in the office you become the subject of a witch hunt. It was the same way 15 years ago if you suggested anything other than SOAP. The more things change, the more they stay the same.

It's often new employees fresh out of college who are the worst. They can be obsessed with doing things 'right', which you can't blame them because they have little experience. The internet tells them REST is right, so anyone who doesn't agree with them is wrong.

Re: REST is the new SOAP

#252

Post by BerislavLopac »

Cyphase wrote: post #245
bvrmn wrote: post #148

Earlier quoted context omitted.

> Why is REST so popular? REST is not popular, there are only a few RESTful public API in the wild. The rest (unavoidable pun, sorry) are simple HTTP APIs with JSON serialization which maps with various degree of coupling to internal data layer. The main cause you don't need REST limitations to achieve same goals. OP has strong opinion about why we need to reimplement rpc over http every time for every application an…

> The rest (unavoidable pun, sorry) ... The remainder.

Good name for a REST library. ;-)

Re: REST is the new SOAP

#253

Post by pixie_ »

moca wrote: post #246

Both Google and Microsoft have published their API design guidelines, which are very much RESTful. Both companies have applied their guidelines to broader set of products at very large scale. At least, we have not seen alternatives that would be applicable or scalable to companies at Google or Microsoft scale. API design is like UI design or car design or clothes design. It is a form of craft, which does take time an…

Except those carefully designed URLs are often behind a client side RPC library. So what was the point of doing it REST style in the first place?

Re: REST is the new SOAP

#254

Post by amarkov »

thijsvandien wrote: post #217
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…

That's exactly what YAGNI/KISS encourages. Don't make things more complicated than they need to be right now. That includes used technologies. I'd much rather use a simplistic tool while I still get away with it, risking having to switch to a more complicated tool later, than starting off with something way too complicated for what I need. Chances are the difficulty isn't in switching from REST to SOAP, or the other…

But you can't just decide to avoid making assumptions, because the shape of your API strongly dictates the shape of your handler methods. I've never seen an API migration that didn't involve rewriting nearly the entire API layer.

Even worse, you have to maintain both the old and new versions of the API code, because turning off the old API endpoint is going to take at least a year.

Re: REST is the new SOAP

#255

Post by slackingoff2017 »

Grpc is the future, I'm amazed that nobody seems to be using it. Easy endpoint definitions and code generation in almost every popular language. Much faster than REST and zero boilerplate code. The client libraries even have http baked in so no "controllers" or route mapping to write. It's simply fantastic.

If you run into a language without grpc support you just standup a JSON proxy and pretend it's REST.

Re: REST is the new SOAP

#256

Post by megiddo »

When I see articles like this, I recognize a fellow expert.

The same way JSON is better in practicum than XML, despite missing some key tooling, JSON RPC 2 is better than SOAP or REST in practicum because it was designed by someone with experience who had to actually get shit done.

Every time someone tells me that I don't get REST and links me to Fieldings dissertation, all I hear is the bleating of goats and the peals of Dunning-Kruger.

Re: REST is the new SOAP

#257

Post by kasbah »

DarkCrusader2 wrote: post #25
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…

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 "Make Medium Readable Again" extension for when I _am_ interested in the content.

https://github.com/thebaer/MMRA

Re: REST is the new SOAP

#258

Post by tie_ »

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 philosophy, than a standard. Hence everyone does it differently, and you have no chance to use the same library to talk REST with multiple different services (unless you make that library an overcomplicated beast).

XMLRPC? It's a universal standard, that is just a few pages long and everyone can grasp it in their lunch break. Nobody would complain that your API is not "XMLRPC enough". It works (almost) the same way everywhere. You can get the XMLRPC library that's been built in since Python 2.2 and be reasonably sure that you are going to be able to talk to a random modern XMLRPC API. You'd have other such libraries for every major language. Ditto for JSONRPC, if XML sounds too scary (though it doesn't really matter much - it's a mostly transparent implementation detail).

I'd wish people would stop bringing up SOAP as an excuse for REST. Yes, it was worse, but that does not mean that REST is particularly good.

Re: REST is the new SOAP

#259

Post by jack9 »

parasubvert wrote: post #224
coldtea wrote: post #185

Earlier quoted context omitted.

> Why is REST so popular? Because it's easy to implement and works for lots of use cases. Could have given the exact same non-argument for SOAP -- which in its time dominated corporate services. Whether it's "easy to implement and works for lots of use cases", it's a moot point if there would be something even easier to implement and worked even better for real use cases. Why stop at "easy" when you can have easier A…

“Real illuminated REST”? The REST spec? It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles. Some people took this and crafted a quasi religion out of it, but that’s partly because vendors in 2002 were all lined up trying to replace the web with a COR…

The thesis (https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) with relevant section: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...

The HTTP REST came from people mapping HTTP verbs to RESTful actions: http://cafe.elharo.com/web/why-rest-failed/ (2006) to https://martinfowler.com/articles/richardsonMaturityModel.ht... (2010)

Re: REST is the new SOAP

#260

Post by jack9 »

CydeWeys wrote: post #178
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…

I agree with a lot of the things in your post, but this one in particular has produced the most grief for me: > Don't get me started with conflating http server errors with applications errors. I've wasted so much time dealing with 404 errors that were returned by the webserver itself (not the app) because the endpoint I was hitting was wrong or had moved, and vice-versa when I was correctly hitting the app but got a…

I've always made up my own error codes, which I embed in the 200 response since I end up having to map HTTP codes to what they mean anyway, and many libraries have their own behavior on how to handle various HTTP codes or cannot recognize anything other 200 and other (some LUA engines, for example).
Post reply on HN