Looking at URI design, there are a lot of cross-cutting concerns across many a resource. It would be great to come up with some conventions for the most common.
These are some of the ones I've been percolating on.
- You can see there are a broad range, including:
- different views or representations of a resource, around breadth/depth of it's data and relations
- user request based affects on a representation
- resource version
- application supporting mechanisms, returning fragments and forms or form fragments
- temporality
There are a few more, but the trick is having less, right.
| ;version | entity version that is |
| ;_for_edit ;_for_inline_edit | return html fragment |
| ;_at_instant={utc_milliseconds} | get this resource as it would be represented at this point in time |
| ;_for_period=iso8601 format | holidays during these periods/durations. die to start and end date ranges. or ;_for_interval |
| ;_role=admin | |
| ;_repr=code_value | representation of code_value. May also need numcode_value and maybe a triple for code,short name and description |
| ;_repr=summary|detail|depth | you get the idea |
| ;_repr=no_ambiguity | return a 300 Multiple Choices, if there must be no ambiguity in the request. If the request can not fully determine the intended resource. Often in practice a convention will be followed, like the latest version of the resource. If you support multiple versions do you do what wikipedia does and offers a disambiguity page (as a standard OK response). Although disambiguity pages could cause issues in situations where you expect all particular requests of a resource to return same formatted representation ie. no ambiguity. |
| ;additional_param=xyz | #ambiguity resolution |
| ;fragment |
See also ISO8601
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.