4 ms·
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/
by jamesbritt 16y ago
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?
- nikcub 16y agowell 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).
- masklinn 16y ago> 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.
- nikcub 16y ago> 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_style.htm#sec_5_2_2 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
- joecomotion 16y agoThe latter can break caching for some older proxies. Also, I believe safari will ignore your caching/expires headers if you use GET params.
- stevelosh 16y agoWith 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.
- regularfry 16y agoOrdering 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.