Hacker News Reader

Comment by jamesbritt | Hacker News Reader

Besides simply asserting the OP is wrong, perhaps you could explain what differences (aside from aesthetics) there are between

    /rdio/api/1/artist/1/tracks/2

and

    /rdio?api=1&artist=1&tracks=2

Routing code on the server can treat them as identical; is there anything about these two URL formats that would trip up a client?

Does it change how caching might work?

View on HN

With the first format you can use the same name more than once:

    /rdio/api/1/artist/1/tracks/2/artist/1

I'm pretty sure the ordering of query parameters isn't a part of the HTTP spec.

I just did a quick check and Django, for example, will just take the second of any duplicated GET params.

Ordering of query parameters is a W3C recommendation:

  http://www.w3.org/TR/REC-html40/interact/forms.html#form-content-type

If Django's ignoring repeated form fields, it's Doing It Wrong.

You're right about the ordering, so I guess Django is actually doing it wrong.

You have to use the "getlist" method instead of "get" if you are expecting multiple values.

well I believe both are not correct.

the idea is that you can build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work, in the same way we can now with web browsers

a REST client will never figure out /api/1/ - which is why resources go in the path and query parameters go in as, well, query parameters :)

from the server side you are right that modern front controllers and routing can make it all the same (heck, I can route resources to different subdomains, if I want), but a proxy does not know what the front controller logic is (ie. working backwards to what part is what).

> the idea is that you can build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work, in the same way we can now with web browsers

That's a stupid idea. REST is built on two things: content types and resource location. The content types indicate the meaning and location of the resources, if the client does not understand the content-type, it can not do anything.

You can not "build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work", that makes no sense. Indeed, that's not what web browsers do: the driver of the API on a website is the user, not the browser.

> a REST client will never figure out /api/1/ - which is why resources go in the path and query parameters go in as, well, query parameters :)

That's completely irrelevant.

> That's a stupid idea. REST is built on two things: content types and resource location.

here is what my generic REST client looks like:

* HTTP[s] * JSON * Atom and RSS * Caching layer

some controller login in between all of these. I inherit this to implement simple models and controllers in the client and just tell it which resources I want (like fields in a database)

how is that not a generic client?

for twitter I have classes called users and statuses, with each method defined. for google I have similar classes. this all took minutes for me to get working - I thought that was the entire point of REST?

read the original desertion, sec. 5.2.2 connectors:

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...

> if the client does not understand the content-type, it can not do anything.

generic doesn't mean understanding the payload, it means understanding the protocol

The latter can break caching for some older proxies.

Also, I believe safari will ignore your caching/expires headers if you use GET params.

Reply on news.ycombinator.com