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

51–60 of 351 posts

Re: REST is the new SOAP

#51

Post by IanCal »

speedplane wrote: post #30
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 net…

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.

Re: REST is the new SOAP

#52

Post by bthornbury »

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…

You're right of course, like the first time you hit a race condition (with a week of debugging) and build a distributed lock system. You publish it and people find it useful!

Only to realize later postgres offers fine locking capabilities far beyond what you've created (now that you get it).

Then you realize that all anybody is doing is creating subsets of Erlang (half serious). So why aren't we all using that?

In the grand scope, is it really a bad thing?

We end up with X ways to solve problem Y and you never know X + 1 could have some advantages. Exploration should be encouraged IMO!

Re: REST is the new SOAP

#53

Post by blowski »

Lazare wrote: post #7
blowski wrote: post #2

So for reasons unclear you tried to replace a working system with a design pattern you didn’t really understand, and you were disappointed with the results? What were you hoping to get from this madness? Honestly, REST is a great idea. Yes, people get religious about HTTP verbs and URL structures. But you don’t need to. Prioritise clarity to humans above everything else, and you’ll be fine for the most part.

> Honestly, REST is a great idea. Yes, people get religious about HTTP verbs and URL structures. But you don’t need to. Prioritise clarity to humans above everything else, and you’ll be fine for the most part. I've seen this argument before (I've even made this argument before), but I'm becoming increasingly unconvinced by it. Let me explain my thinking: 1. If there's ANYTHING that sets REST apart from a generic HTTP…

REST is a design pattern, and like all design patterns, it can be over-applied.

Bits of your application that have natural nouns - “post”, “credit card”, “product” - fit naturally to endpoints. Log in doesn’t, so don’t try shoehorning it in. If only 80% of your application can be defined as REST level 4 but is clear and easy to use, who cares? And if your domain doesn’t fit well with REST, then don’t use it!

Personally, if I have an object like “product” and want to use some custom verbs, I include them in the “links” section of the product response. My authentication process is in the documentation, with /login and /logout URLs.

My first priority is always to make something usable by humans. I try to do that using REST wherever possible, because usually those goals go together. When they conflict and I can’t resolve them, I choose usability by humans over strict REST principles.

Re: REST is the new SOAP

#54

Post by tmp123tmp123 »

Nope. Rest is stateless, which means it is a form of message passing - the right thing to do (a universal design principle, like a pipeline, etc).

Soap is just a crap by a committee of idiots.

If you like this blue is new white pattern, consider Javascript is new J2EE instead.

Re: REST is the new SOAP

#55

Post by wobbleblob »

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.

Re: REST is the new SOAP

#56

Post by IanCal »

speedplane wrote: post #33
hliyan wrote: post #16

Earlier quoted context omitted.

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…

You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.

That means I can't use any kind of generic retry / back off code because I've now got to start dealing with your custom errors, and if you have html versions of the info Google will start demoting you.

Just add a code, it's seconds of work.

Re: REST is the new SOAP

#57

Post by qaq »

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…

And yet most popular "REST" APIs provide lang. specific clients that expose regular function calls to consume the API turning it into RPC.

Re: REST is the new SOAP

#58

Post by kiallmacinnes »

speedplane wrote: post #33
hliyan wrote: post #16

Earlier quoted context omitted.

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…

You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.

I disagree, at a minimum, use 200/400/500. Each grouping of error code defines semantics which are implemented by generic clients / servers / middle boxes / monitoring agents etc. These are things out of your control, and often ran by a range of different companies. Debugging these is .. hard.

Re: REST is the new SOAP

#59

Post by lfischer »

Maybe REST was the best protocol for the great public API explosion of the past decade, where startups wanted to expose a public API to anyone on the internet. The most important requisite was that the most developers could access the API with a minimum of technical knowledge and tools, and the APIs were simple. I am less and less sure that REST is the best solution for communicating between internal services, which know a lot about each other and where you can spend time onboarding developers on a specific techniques and stack.

Re: REST is the new SOAP

#60

Post by speedplane »

fleetfox wrote: post #48
speedplane wrote: post #33

Earlier quoted context omitted.

You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.

What a horrible advice, just because you are too lazy to return correct status code someone who consumes the api has to do twice the work.

Not at all. Some languages and libraries don't handle non-200 status codes nicely, they may raise exceptions for each code, or maybe not. For example, Python's basic urllib library makes it easy to get 200 responses but a hassle to get anything else (you need to wrap it in a try/except).

For some APIs, it definitely does make sense to use proper status codes, but for others, it's like fitting square pegs into triangular holes.

Post reply on HN