4 ms·

No, those are not part of a REST API. You've got it wrong.

by swombat 16y ago

justincormack 16y ago
Actually URLs are supposd to be opaque in rest so that is correct. Nice urls with http verbs but no hateos is what most "REST" APIs are though.
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 ago
  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).
  - 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 ago
  The 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 ago
  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.
  - regularfry 16y ago
    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.
    - stevelosh 16y ago
      You're right about the ordering, so I guess Django is actually doing it wrong.
      - ramen 16y ago
        You have to use the "getlist" method instead of "get" if you are expecting multiple values.
masklinn 16y ago
Behold, the know-nothing. Sorry sir, I'm not wrong, those would be perfectly valid as part of a REST service, including as alternatives to tptacek's description. Readability of the URLs has nothing at all to do with RESTfullness. The only thing REST says about the data transmitted (the URL in this case) is that it's the container for the application's state, and most interpretations of this is that the URL is entirely opaque. And indeed, Fielding has suggested/explained this several times.
- swombat 16y ago
  See http://en.wikipedia.org/wiki/Representational_State_Transfer http://en.wikipedia.org/wiki/Representational_State_Transfer Those are not REST because they are not resource-based. Correct REST: http://blah.com/widget/:id http://blah.com/widget/:id - GET, PUT, POST, DELETE How does that fit with your /rdio/4E7?q=1 ? Where's the resource? What is the id? What is q anyway? You can pass parameters with a ? in REST... for example, you might do GET http://blah.com/resource/123?format=xml http://blah.com/resource/123?format=xml But there's still a clearly identified resource which the GET is performed on. Sure, technically, by stretching things a bit, you could claim that /rdio?q=1&s=63-8 is a REST GET request for resource id "63-8". And, technically, you'd be right, much like technically, this is valid C: http://stackoverflow.com/questions/18642/what-is-the-most-unreadable-programming-language/18767#18767 http://stackoverflow.com/questions/18642/what-is-the-most-un... But just because it's valid doesn't mean it's in any way good. Those are horrible examples. So no, those URLs could not "just as well" be those nasty examples you give. They could, much more poorly, be those examples, and still be technically valid. By the same reasoning, "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" is just as good english as Shakespeare.
  - Darrel 16y ago
    All query string parameters are used to identify the resource also. RFC 3986 states "The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)." There is absolutely no difference between path segments and query parameters from the perspective of resource identification.

No, those are not part of a REST API. You've got it wrong.

by swombat 16y ago

No, those are not part of a REST API. You've got it wrong.

Actually URLs are supposd to be opaque in rest so that is correct. Nice urls with http verbs but no hateos is what most "REST" APIs are though.

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 ago
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).
- 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 ago
The 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 ago
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.
- regularfry 16y ago
  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.
  - stevelosh 16y ago
    You're right about the ordering, so I guess Django is actually doing it wrong.
    - ramen 16y ago
      You have to use the "getlist" method instead of "get" if you are expecting multiple values.

masklinn 16y ago

Behold, the know-nothing. Sorry sir, I'm not wrong, those would be perfectly valid as part of a REST service, including as alternatives to tptacek's description. Readability of the URLs has nothing at all to do with RESTfullness. The only thing REST says about the data transmitted (the URL in this case) is that it's the container for the application's state, and most interpretations of this is that the URL is entirely opaque. And indeed, Fielding has suggested/explained this several times.

swombat 16y ago
See http://en.wikipedia.org/wiki/Representational_State_Transfer http://en.wikipedia.org/wiki/Representational_State_Transfer Those are not REST because they are not resource-based. Correct REST: http://blah.com/widget/:id http://blah.com/widget/:id - GET, PUT, POST, DELETE How does that fit with your /rdio/4E7?q=1 ? Where's the resource? What is the id? What is q anyway? You can pass parameters with a ? in REST... for example, you might do GET http://blah.com/resource/123?format=xml http://blah.com/resource/123?format=xml But there's still a clearly identified resource which the GET is performed on. Sure, technically, by stretching things a bit, you could claim that /rdio?q=1&s=63-8 is a REST GET request for resource id "63-8". And, technically, you'd be right, much like technically, this is valid C: http://stackoverflow.com/questions/18642/what-is-the-most-unreadable-programming-language/18767#18767 http://stackoverflow.com/questions/18642/what-is-the-most-un... But just because it's valid doesn't mean it's in any way good. Those are horrible examples. So no, those URLs could not "just as well" be those nasty examples you give. They could, much more poorly, be those examples, and still be technically valid. By the same reasoning, "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" is just as good english as Shakespeare.
- Darrel 16y ago
  All query string parameters are used to identify the resource also. RFC 3986 states "The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)." There is absolutely no difference between path segments and query parameters from the perspective of resource identification.