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

21–30 of 351 posts

Re: REST is the new SOAP

#21

Post by doque »

hliyan wrote: post #16
dhoulb wrote: post #10

This article expressed a lot of what I’ve been mulling for years. I must’ve spent hours of my life poring over the Wikipedia HTTP Response Codes page, looking for the most expressive error code for my situation. It’s barmy.

You don't need to. For me, REST can be as simple as: encode the type of request into the URL, request parameters into URL parameters and/or query parameters, request data into a JSON payload. Use GET for read-only operations, and if you're really not particular about it, use POST for everything else. Return 200 for success, 400 for client error and 500 for server error. Transport a more detailed application error cod…

I agree. There are plenty of freedoms built into the REST way that enable you to create more or less detailed responses.

  "I don’t care. Trees are recognized by their own fruits.
   What took me a few hours of coding and worked very robustly, with simple RPC, now takes weeks..."
Weeks? For a REST API? No, I don't think so. REST gives you the tools to be pragmatic and quick, so use them.

Re: REST is the new SOAP

#22

Post by raverbashing »

While REST is much better than the alternatives, the criticism is on point

Some people take religious discussions about REST to the extreme (usually about not being RESTful enough)

The same extremists probably never met real world problems or did some questionable quirk to solve them that they sell as true gospel.

Re: REST is the new SOAP

#23

Post by assafmo »

bbarn wrote: post #14
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…

Well, I'm glad you can put together an RPC api that quick, but the reason REST is so ubiquitous and why arguing against it is going to make you the subject of a witch hunt is because it's so easy to consume. Your API is useless if people don't want to use it.

I agree. My main goal building an API is to make it easy to consume.

Clients are lazy and impatient, and this is a good thing because it makes the developers work hard to make it easy to connect to their API.

Re: REST is the new SOAP

#24

Post by speedplane »

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 function calls, and the fact that REST calls are relatively distinct from normal function calls is a good thing.

Re: REST is the new SOAP

#25

Post by DarkCrusader2 »

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?

Re: REST is the new SOAP

#27

Post by speedplane »

andrei_says_ wrote: post #20
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 think “hipsteresque opinions looking to sound smarter and more insightful than they actually are” is a very good definition for much of Medium’s content. It may have to do with the platform being used by individuals trying to create a brand of themselves, resulting in a high percentage of sensationalist and controversial posts. Along with the necessity to write on a regular basis.

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.

Re: REST is the new SOAP

#28

Post by adrianmsmith »

gjjrfcbugxbhf wrote: post #11

The author seems confused between 401 (not logged in) and 403 (user doesn't have permission).

Agreed: 401 is for authentication and 403 for authorization.

Yet the official name for 401 is 401 UNAUTHORIZED.

So even the very basics of REST and HTTP are confusingly or ambiguously defined.

Re: REST is the new SOAP

#29

Post by speedplane »

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're defining an RPC protocol in just a few minutes, you're leaving a ton of stuff out. Anyone that assumes an RPC call will successfully complete or assumes the network is always there, is writing buggy code. An "RPC protocol" makes writing such buggy code easier. A REST protocol makes it slightly harder. In theory, they are almost identical. But in practice, developers equate RPC calls with function calls, which they are definitely not.

Re: REST is the new SOAP

#30

Post by speedplane »

hliyan wrote: post #5

I feel like this is the root of the author's agitation: "I don’t care. Trees are recognized by their own fruits. What took me a few hours of coding and worked very robustly, with simple RPC, now takes weeks..." He seems unhappy that REST doesn't work the way his familiar tool (RPC) does. I myself worked with middleware-messages-over-TCP systems for a decade before switching to web apis. I don't have this issue. And I…

The problem is the assumption of a "simple RPC" protocol... there is no such thing. There are network issues, proxy errors, and two-sided race conditions that complicate any network related code. Network programming is distributed programming, which is not easy. RPC protocols try to mask that difficulty, but more often than not they sweep it under the rug.

RPCs make it easy to get started on a dev machine. making network calls appear like function calls definitely speeds things up when the network is working perfectly, but it papers over the complexities of debugging network issues and complex distributed race conditions, which will inevitably come up later.

Being explicit with network communication has its benefits.

(corollary: for the same reason as above, I don't like lazy evaluation of database queries that exist in many languages. When you hit a database, it should be intentional, you should know about it, and should properly prepare for any necessary network issues, caching, and cursors. Many modern web frameworks gloss over this).

Post reply on HN