5 ms·

My two cents: - if your queries get that complex, introducing a subordinate query resource is a pretty reasonable measure; in a world where people commonly use

by dyoder 12y ago

My two cents: - if your queries get that complex, introducing a subordinate query resource is a pretty reasonable measure; in a world where people commonly use URL shorteners, why is this controversial? - "don't break the web" isn't just about bookmarks; it's also about interoperability, in general - for example, supporting GET means responses are now cacheable, which may be useful in many situations - the author is mostly just pointing out that DropBox hasn't followed the REST style, and he's correct; there are reasonable design alternatives that do - therefore, if REST is good, than this design is bad; given the success of the Web and HTTP, whose fundamental design follows the REST style, it always mystifies me how many people find this objectionable

treve 12y ago
I think the main problem people have with this, is that REST is not necessarily easy. And easy sometimes wins over 'good'.
- dyoder 12y ago
  you're absolutely right. and i'd be fine with that if the objection was just that: this is too hard to implement, or we don't have time, and so on. it's the rationalizing that's annoying. and obviously DropBox has the resources to implement whatever design they choose.
- cauterized 12y ago
  Strict REST can also result in a lot more requests than a denormalized API might, and that's mobile-unfriendly.
  - dragonwriter 12y ago
    Strict REST doesn't require normalization; there is nothing in the definition of the REST architectural style that prohibits resources that are aggregates of -- in DB terms, equivalent to whole tables, or rows from a complex view, or whole complex views -- of other resources, and allowing those derived resources to be directly retrieved or manipulated (with the latter also affecting the "base" resources.) The kind of REST that simply maps resources to DB rows with collection resources for base tables and does nothing else is naïve REST, not particularly any stricter REST than more complex and application-suited resource models.
sstradling 12y ago
Agreed. Particularly "don't break the web". Points and kudos for a clean solution to complicated GET queries.

by dyoder 12y ago

treve 12y ago

I think the main problem people have with this, is that REST is not necessarily easy. And easy sometimes wins over 'good'.

dyoder 12y ago
you're absolutely right. and i'd be fine with that if the objection was just that: this is too hard to implement, or we don't have time, and so on. it's the rationalizing that's annoying. and obviously DropBox has the resources to implement whatever design they choose.
cauterized 12y ago
Strict REST can also result in a lot more requests than a denormalized API might, and that's mobile-unfriendly.
- dragonwriter 12y ago
  Strict REST doesn't require normalization; there is nothing in the definition of the REST architectural style that prohibits resources that are aggregates of -- in DB terms, equivalent to whole tables, or rows from a complex view, or whole complex views -- of other resources, and allowing those derived resources to be directly retrieved or manipulated (with the latter also affecting the "base" resources.) The kind of REST that simply maps resources to DB rows with collection resources for base tables and does nothing else is naïve REST, not particularly any stricter REST than more complex and application-suited resource models.

sstradling 12y ago

Agreed. Particularly "don't break the web". Points and kudos for a clean solution to complicated GET queries.