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

211–220 of 351 posts

Re: REST is the new SOAP

#211

Post by criddell »

niftich wrote: post #201

I author REST APIs and try to do them properly, with mediatypes, link relations, and all the good hypermedia stuff most people avoid. Nonetheless, the author's post reflects the sort of rant I've had to coworkers at the watercooler, or anyone who'd listen. The author nicely preempts the debate about HATEOAS and "most RESTful APIs aren't REST" and shows that the debate is part of the problem. It is. It's not a spec bu…

> The author nicely preempts the debate about HATEOAS

What is the debate about HATEOAS?

What's the difference between an API with and without that quality?

Re: REST is the new SOAP

#212

Post by niftich »

jwilk wrote: post #192
IanCal wrote: post #61

Earlier quoted context omitted.

Can I send a large request body with a GET? That's usually the reason I end up with POSTs.

> Can I send a large request body with a GET? Why not?

A GET request's body has no defined semantics, so your server is firmly in the realm of "nonstandard implementation detail" if you choose to take into account the body in your decision-making.

Re: REST is the new SOAP

#213

Post by yongelee »

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?

Medium posters borrow clout from medium which makes their post have clout. If you think of medium posters as just bloggers with their own domain or blogspot, you'll see them differently.

Re: REST is the new SOAP

#214

Post by sebringj »

I think REST's ambiguity and arbitrary nature is a real thing for those that are opinionated. (not me so much) Strange but JSON RPC did away with those types of arguments but wasn't used maybe because the name sounds complicated (two acronyms too much)? Now we have GraphQL that seems to be the best answer in ease of use of consumption and design. Rest easy.

Re: REST is the new SOAP

#215

Post by mistermann »

thinkpad20 wrote: post #167
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…

The article laid out a detailed explanation of shortcomings of REST. You might not agree with everything in it, but you offer no real rebuttal, instead dismissing it as a “hateful hipsteresque opinion,” without acknowledging any of the actual criticisms the author gave. This strikes me as unfair, haughty and lazy.

There's quite a "circle the wagons" mentality common in programming nowadays, following politics lead I suppose.

Re: REST is the new SOAP

#216

Post by osrec »

paulddraper wrote: post #176
osrec wrote: post #174

I find REST APIs a bit annoying, primarily because of caching behaviour. For example, if I have a GET on a list of resources and then PATCH a particular resource from the list, the browser will still keep the old list in cache and not update (with the newly patched resource) till the cache expires. For this reason, I just use my own json APIs using POST requests (to bypass the cache) with some application specific ca…

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.

Re: REST is the new SOAP

#217

Post by thijsvandien »

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 way around, but in dealing with the all the assumptions that permeate those 50 KLOC. In the end it just comes down to having a clean code base that can be steered in another direction.

Note that I only mean not dealing with what cannot be easily be foreseen. Turning a blind eye to what you should know will soon be a problem, is a different story. As an example, if you ignore concurrency from the start, that will be hard to set straight later.

Re: REST is the new SOAP

#218

Post by bogomipz »

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?

>"And what's with the UI on their publications"

Agreed, its a content platform with a where the content fights for attention with the medium.com branding. How many people do you really "never miss a story from"? I generally avoid medium.com for this reason alone.

I'm further puzzled when I see companies using medium for their company blog as well. All I can figure is it must be recommended in some user guide to "growth hacking."

Re: REST is the new SOAP

#219

Post by zaphar »

Rest is not an RPC protocol. If you need RPC you should use an RPC protocol. Rest is not universally applicable. The verbs don't map well to anything beyond simple CRUD operations. If you want to do something that isn't one of those operations it is going to be painful.

You can get all the benefits of the plain text serializataion by using json or even xml as the payload serialization format with a much richer set of verbs. You can even use HTTP as the lower level protocol if you want and gain all the benefits that that gives you.

Most of the pain people experience is when they try to use REST when they need an RPC protocol instead.

Re: REST is the new SOAP

#220

Post by elmalto »

sloxy wrote: post #163
lfischer wrote: post #69

Earlier quoted context omitted.

I don’t know yet because I haven’t had as much experience with other solutions as with REST. I am curious about Thrift and Protocol Buffers. I have worked once on a project migrating from REST to Protocol Buffers for an internal API and it noticeably improved performance, but code complexity remained more or less the same.

> Protocol Buffers Well, REST is architecture. Protocol Buffers are (de/)serialization. I've tried it before (& although it has the properties I like[language agnostic schema definition..]), it was finicky to get working with of one the biggest IDEs out there(IntelliJ IDEA) Also, it doesn't support Kotlin yet.(Java interop only option) The only place I can see Protocol Buffers being useful is inside Google..cos it wa…

I use protobuf at work all the time (not google) and prefer them over almost all other serialization formats. To be fair, I mainly work in Scala, C# and JavaScript where great implementations exist. In the case of Scala, IntelliJ just needs to know that the generated source files are just that and then it „just works“ for me
Post reply on HN