Hacker News Reader

Comment by ryanbrunner | Hacker News Reader

I don't disagree with most of the rules, but it's more than a little ironic that the supporting quote at the top of the page that the article seemingly hangs off directly contradicts most of the article:

> The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain other information.

- Tim Berners-Lee

By this quote, caring about the hierarchical nature of URIs, pluralization, and enhancements to readability are somewhere between irrelevant to actively harmful (since they promote the idea that the URI contains information beyond identification)

By the logic that a URI is supposed to be used for identification and identification alone, these two URLs are identical in terms of value:

http://api.example.com/louvre/leonardo-da-vinci/mona-lisa

http://api.example.com/68dd0-a9d3-11e0-9f1c-0800200c9a66

View on HN

Most compilers interprets variables name as opaque identifiers without semantic meaning. Does that mean I should not have rules to name variables?

The way I interpreted the quote is: Don't parse the URI in your program to try to gain information about a resource other than it's ID. It doesn't mean you can't put information in there to make it easier for human developers to understand.

In other words, pretty names are for humans, not machines.

And in a 'true' REST API the pretty name for humans should be in the link text, not the href

Yes, The article is talking about REST as in "JSON RPC over HTTP" as opposed to REST as the person who came up with it (Roy Fielding) intended.

If you are worrying about URL readability you aren't doing REST.

Spot on. RESTful URLs are not to be treated like SEO URLs. But unfortunately most people don't see the difference. One example in the article is especially harmful (/students/<id>/courses/physics for querying).

The single best slideshare I've found on REST is Teach a Dog to REST. Old but gold. https://www.slideshare.net/landlessness/teach-a-dog-to-rest

(And a shameful plug - https://medium.com/@rdsubhas/pitiful-restful-urls-5d576ffccb...)

  > RESTful URLs are not to be treated like SEO URLs

But it does not hurt to have them human-readable.

It does hurt. Examples in the article linked above.

Most web apps (outside of websites themselves, which are a kind of very simple application) aren't HATEOAS, so Roy's thesis has less purchase on their design.

In most contexts what you actually need is REST as in "JSON RPC over HTTP" instead of REST as Roy Fielding intended.

So the recommendations in the article are actually valid and useful, but we'd need to come up with another name to properly distinguish which "REST" we're talking about, at least unless/until one of these usages fades into obscurity.

> we'd need to come up with another name to properly distinguish which "REST" we're talking about

"Underspecified, broken half-implementation of RPC" is quite precise, but most of the programmers don't like being reminded that they implement a brain-dead idea.

I never understood why people don't use one of the already-defined RPC protocols, rolling instead their own versions (each different) that don't even signal errors properly.

Reply on news.ycombinator.com