Hacker News new | past | comments | ask | show | jobs | submit login

> Is the web a really a model we want to emulate?

I can't think of a single more successful achievement of software engineering, so can someone explain why I shouldn't answer with an emphatic, "yes!" to this question?

I get the web has all kinds of flaws, and maybe we can do better, but as far as I know, we haven't even come close to actually building something as useful or ubiquitous or stable as the web.

I've been using redis pipes (and databases in general) to get services to talk to one another, and that has its uses, but why must I do that or do REST? Why can't there be a place for both?

> I can't think of a single more successful achievement of software engineering, so can someone explain why I shouldn't answer with an emphatic, "yes!" to this question?

Because you've taken a single question from TFA out of context as a straw-man. Yes, the web has been enormously successful. But that's simply irrelevant to the practical questions posed by the author. To stitch together the full question that Ben Morris is really posing using a quote from the article:

Is the web a model we really want to emulate [as] "the only collaboration fabric for a large and complex set of decoupled, autonomous and collaborating services"?

To which I could just as emphatically quip "no!" Note the "only" in there. Morris is explicitly not throwing REST out, but questioning the REST-uber-alles mindset by pointing out limitations of that paradigm.

Immediately after the quote you pulled comes (IMO) the best part of the article:

It’s not just HTTP that provides a limited model for service integration. The web has been an inspiration for REST but is it really that successful a distributed system? It’s slow, fragile and prone to security problems. It’s vast, decentralised nature makes it impossible to find anything useful without indexing engines that are so vast that only one or two companies have been able to create them.

It's not, again, that the web isn't successful. It's that the applicability of solution to problem is being questioned.

Maybe the article could have been more succinct with some SOA jargon but a service description language (WSDL) and service discovery system (UDDI) are important and not really a well solved problem in practice despite the multitude of standards made back in the 90s. So, the question posed to me by the author is what has REST provided for us so far that we should continue to expand upon that it solves legitimate concerns of enterprise architectures. I can say for sure that UDDI failed in enterprise by now and with REST it really seems like we've stopped progress there anyway. Instead of either, everyone has moved to message passing architectures that accept the reality that services are extremely varied in maturity and semantics across the enterprise world. REST is about as vague of a standard as AMQP or even JMS as far as service standardizations and ontologies go.

To me REST in enterprise is simply reflective of how broken SOAP and XML-RPC was in practice in enterprises and made for far too inflexible, monolithic services that'd take years to move forward major versions. You can decompose REST respurce URLs at least and try to scale out from there instead of being stuck to the service definition's XML schema for every resource definition. Sure, I've seen some Schemas that are composed but in the world of enterprise software vendors and internal bureaucratic services you will devolve to the pathological cases of simplicity in your architecture to get the bare minimum done, and REST works better in practice here than anything WS standards related.

But he doesn't mention a lot about alternatives. Of course we could try to avoid having a single solution for everything but if there is no better option right now then REST can and should be used. If his point was to say that REST only works in some limited circumstances then he should have said what those were and, again, what other option we have for the other cases. I still think REST works for a lot of things but you might want to add some extra tips or standards within an organization.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact