Hacker News Reader

Comment by coding123 | Hacker News Reader

My largest gripe with REST is that it's a very lock-in technology. Once we evolve past REST instead of being able to decouple cleanly from the underlying protocol, we're pretty much trapped in status codes and methods that lock us in. At least with GraphQL there's a clean break. Everything should have been focused on the payloads, not the transport layer.

View on HN

> My largest gripe with REST is that it's a very lock-in technology.

I can't really think of a technology less subject to lock-in than REST; reliance on specified resource representations and HATEOAS makes it agnostic to pretty much everything.

EDIT: I guess there's lock-in in the sense that once you have REST, everything else is too limiting.

> Once we evolve past REST

Few things even reach REST, much less evolve past it.

> instead of being able to decouple cleanly from the underlying protocol

REST starts out decoupled from the underlying protocol(s), it's not something you need to do when evolve past REST.

> Everything should have been focused on the payloads, not the transport layer.

The only thing that REST says about the transport layer is that one should avoid altering or extending the semantics of the underlying transport protocol(s) except as necessary to cover gaps that have no suitable coverage. REST is all about the payloads plus HATEOAS.

On top of what others have already said: GraphQL is a "clean break" that breaks with everything: idempotency (POST requests are not idempotent), caching (POST requests cannot be cached), version control and partial updates (GraphQL eschews ETags), etc. etc. etc. There is value in underlying protocols and there's value in using those protocols. GraphQL servers end up re-implementing, poorly, half of HTTP, and patting themselves on the back for it.

Edit: for those interested, here's HTTP decision diagram that REST takes full advantage of: https://github.com/for-GET/http-decision-diagram/tree/master...

I'm not sure what's your personal definition of REST but REST according to Roy Fielding's definition is an architectural style that helps design APIs that are as loosely coupled as it gets. In fact, I'm not sure what style of APIs you feel improves upon REST on this criteria.

Not sure I follow. Why is REST lock in? Because it can only be used in a single service?

S3 API for example is probably a counter example. But it shows that the lock in is not inherent to REST, no?

REST is an architectural style and while the decision to use the style may lead to "lock in", it in and of itself does not given it's a choice to use it or not.

Couldn't I say that about anything that leads to lock in?

Reply on news.ycombinator.com