undefined | Better HN

0 pointsmbleigh11y ago0 comments

I'm speaking from the experience of a developer who has built numerous public APIs and client libraries over the years. Yes, you still need documentation for a REST API (I'm not a HATEOAS utopian), but you can easily attach your documentation to concepts with which many (probably most) developers are already familiar.

The article is basically saying "You know how lots of cars have steering wheels and pedals? Well, I think it's annoying to build cars that way, so I'm going to use a system of levers and buttons." There's a ton of utility in anchoring new systems to familiar concepts, and unless you have a good reason not to you should strive to do so.

0 comments

1 comments · 1 top-level

drinchev11y ago

I totally agree. That's my first argument against the idea of the OP.

In these days you have out-of-the-box so many already working API clients and already so many public API End-points that it would be really, really hard to create some ( opinionated ) better way of doing this.

Libraries like Backbone and platforms like NodeJS ( and many more ) have this idea so deep that it becomes extremely easy to create an API front-end / back-end app with just a matter of a couple of files ( even lines ). This is becoming standard in other platforms as well.

I think the debate is long time shifted from "Is REST good for my app?" to "How to best follow RESTful principles in my app?"

j / k navigate · click thread line to collapse