Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If that is true, why do so many guides stress URI design?

The canonical example is the "collection" URI,

    http://example.com/resources/
And the "element" URI,

    http://example.com/resources/item17
Would anybody balk if all my REST API's URIs where obscure hashes?

So my collection is now,

    http://example.com/b9cbc0a72a17e6b9e271187096c3b981269554fb
And the element is,

    http://example.com/7c2186f626d0aa7dedc0bb7537b578937015ff6e
Is this no worse or better?


Worse and better are subjective; but neither version impacts on whether the system is REST or not, since they don't break any of the constraints, are defined by Fielding: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...


> If that is true, why do so many guides stress URI design?

Because these guides are written for people who don't understand what they're talking about?

> Would anybody balk if all my REST API's URIs where obscure hashes?

> Is this no worse or better?

In terms of "RESTfulness" there is no difference whatsoever.

In terms of clarity, readability and debuggability, the former is better.


This is not so much specific to REST (although very common), it is more in the realm of TBL's "Cool URIs don't change" about URI design [1].

Even though the actual call to the REST service is opaque there is always a person that creates the calling application. Design an API that you would like/enjoy developing against.

[1] http://www.w3.org/Provider/Style/URI.html


The difference is people who's goal is to follow some pure, academic definition of REST and people who want to make elegant web services. So,

Pedantic wanks "no worse".

People working in reality "wtf would you ever do that?"


What a strawman. Just because URI layout is orthogonal to REST does not make it a non-concern to REST proponents. It has nothing to do with REST. It is a good practice. Both are true.

It's only confusing if you think REST nebulously means merely "good web API design" or "good usage of HTTP."




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

Search: