Timeline for RESTful API design using HATEOAS - Decision on Structure
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2020 at 15:44 | comment | added | Jason Desrosiers | @wired_in REST in Practice is my favorite book on REST :-), but it's been a few years since I've re-read it. As influential as it was, my experience and research on hypermedia systems have also influenced my understanding of these concepts. No, URLs are not defined to be unique, but they are effectively unique because generic components don't know your domain's semantics and thus can only treat them as unique. You'll avoid a lot of problems with intermediaries like caches if you think of them as unique. Consider it a rule of thumb if not a rule. | |
| Apr 13, 2020 at 15:44 | comment | added | Jason Desrosiers | @wired_in In your example of filtering a list using query params, the resource is the list, not the items in the list. If you change the filter, you get a different list. REST has no concept of a list of resources, or sub-resources, or child-resources. That's semantics that we add, but the system doesn't know. Again, think of an HTTP Cache layer. The cache doesn't know that it has a list of resources. It doesn't even know that what it has represents a list. Working with caches has driven this concept home for me. | |
| Apr 13, 2020 at 6:46 | comment | added | wired_in | The query parameters may help identify a resource, which is different from saying that each value of a query parameter constitutes a unique resource. My example above clearly demonstrates this. Notice that U in URI stands for "Uniform", not "Unique". It is an identifier, but that doesn't mean that you can't have multiple identifiers for a single resource. This comes straight from the book "Rest in Practice: Hypermedia and Systems Architecture" | |
| Apr 13, 2020 at 0:10 | comment | added | Jason Desrosiers | @wired_in As for query params, RFC 3986 states "The query component contains non-hierarchical data that, along with data in the path component, serves to identify a resource". It's just an alternate pattern for identifying a resource. Any semantics that your server gives to any part of the URL is irrelevant to the system as a whole. If it's not identified by the same string of characters, the system will treat it like a different thing. | |
| Apr 13, 2020 at 0:09 | comment | added | Jason Desrosiers |
@wired_in URI stands for Uniform Resource Identifier. It's whole reason for being is to identify resources. Although it's possible to write a server that treats two URLs are the same resource, it's effectively two separate resources to the system. Consider an HTTP caching layer. It can't give you a cached version of /orders when you request /clients/{id}/orders. It doesn't know that you intended those to be the same resource. That's why there are multiple mechanisms to indicate that URL is not the canonical URL for the resource including status codes, headers, and link relations.
|
|
| Apr 12, 2020 at 21:53 | comment | added | wired_in | In addition, saying that adding query parameters to a URL makes it a different resource also doesn't make sense. In your example, you are filtering based on fields, you are returning a different representation of the same resource, sure. But what if your filtering query parameter was on the value of a field. /clients?state=VA for instance doesn't change the structure (representation) of the resource, it simply filters which results are included. So you have two different URLs, but certainly not two different resources, or even two different representations | |
| Apr 12, 2020 at 21:46 | comment | added | wired_in | This is misleading. A URL is not a unique identifier for a resource. It's not even a unique identifier for a representation of a resource. There is a one to many relationship between resources and URLs, and a one to many relationship between representations of a resource and URLs. It is perfectly valid to have /orders and /clients/{id}/orders, both pointing not only to the same Orders collection resource, but to the exact same representation, just within a different context. You are only correct in saying one URL can't point to more than one resource. | |
| Feb 26, 2020 at 3:34 | vote | accept | Shubham | ||
| Feb 25, 2020 at 20:30 | history | answered | Jason Desrosiers | CC BY-SA 4.0 |