Hacker News Reader

Comment by debacle | Hacker News Reader

My thoughts:

1. Most people who think that REST is The Best Thing Evar don't really understand what REST is.

2. Most people who think that REST is terrible don't really understand what REST is.

REST is a tool. It's useful for a lot of things. It can alleviate initial scalability issues. It can make an API easier to use or require fewer calls. It can make it easier or more intuitive for someone to learn an API, and it's very often easier to make changes to a REST API because of the way it is written.

But it's just a tool, and if you can't grok that, you're probably a tool as well.

View on HN

So only true scotsmen aren't tools? I'd argue that if a concept is so badly explained that both its most zealous proponents and antagonists are mistaken, that perhaps it's not such a useful design concept in the first place.

I mean, who could possibly be confused about what the transfer of representational state means?

We're getting off track here, so I'm going to recuse myself, but I would argue that the most zealous proponents and antagonists of any concepts are likely mistaken, in some way.

since when does a concept need to be easy to explain for it to be great? Ever heard of general relativity or quantum physics?

Those are laws of nature, not design paradigms. They have different (almost opposite) metrics for "great". Relativity (both variants) and QCD are "great" precisely because they were discovered and characterized in spite of the fact that they are counterintuitive and difficult to visualize.

Good software design, on the other hand, is all about human communication. And a design paradigm that can't be communicated easily has less value than one that does.

> But it's just a tool, and if you can't grok that, you're probably a tool as well.

Unnecessary. All tools have a learning curve, a conceptual slope leading to the sweet spot. Being low on the curve does not make one a tool.

I don't believe passing judgement on something you don't fully understand is a good quality to have, even if it gets your blog more hits.

I agree with the "it's just a tool" sentiment in general, but what other great alternatives are there? I haven't had a favorable experience with SOAP, so I can understand why people think REST The Best Thing Evar. This is based on my own experiences, so I may have used SOAP wrong, misunderstood its intentions, etc. Do you have any examples of when SOAP (or another technology) is preferable to REST?

You can write RESTful SOAP, I don't think the two ideas are perpendicular. The problem with SOAP is more implementation than spec - PHP SOAP is different from .NET SOAP which is (slightly) different from Java SOAP, which leads to headaches.

REST is just a style of API. You can write a JSON API that isn't RESTful just as easily, and in some cases a RESTful API is not warranted.

Do you have an example of RESTful SOAP? I think SOAP's lack of situational HTTP method adoption (i.e. it uses GET or POST for everything, vs DELETE/PUT/etc. when appropriate), and the fact that it wraps another envelope around an already available HTTP envelope makes is hard to deem any SOAP implementation as RESTful. I'm not trying to prove you wrong, I'd just like to see an example (a quick google search yielded nothing for me).

REST was initially described in the context of HTTP, but is not limited to that protocol. You could write a RESTful SAML in SOAP in JSON API, if you desired.

Fox Sports has a pretty restful XML API. I can't remember if it's SOAP specifically, though.

I think you may be confused on the meaning of 'perpendicular'

Nope. Guy's got it right. 'Perpendicular' (or 'orthogonal' if you prefer), meaning that the concerns are on separate axes, and thus independent of each other.

SOAP is a bit weird because it's both an envelope/delivery mechanism as well as a discovery/interface negotiation methodology.

REST is just straight up a set of interface design principles. It doesn't care what you're delivering, it doesn't care about the channel you deliver it through.

Um... "You can write RESTful SOAP, I don't think the two ideas are perpendicular." (emphasis mine)

He's saying they aren't perpendicular and also saying they are independent.

RESTful SOAP? To read anything you have to POST the SOAP envelope.

That doesn't make it impossible to do. REST is traditionally implemented on HTTP, but the core goals and methodologies could be implemented over any protocol.

The "other thing" for us is is RPC and PUB/SUB patterns over sockjs (which wraps Websockets+fallbacks).

REST is a tool. But given an engineer a tool like a hammer and pretty soon everything will look like a nail. Sometimes you need a screwdriver when you actually have screws. Hammering them in will work but it is ugly.

Yeah I considered PUB/SUB as another alternative, and it makes sense to use it for realtime applications, but I'm not sure what else (due to my ignorance, not necessarily PUB/SUB limitations). As for RPC, isn't SOAP the successor to that?

Reply on news.ycombinator.com