Clarify top-level links #262
Conversation
Addresses #250
| A top-level `"links"` object **MAY** be used to specify URL templates that can | ||
| be used to formulate URLs for resources according to their type. | ||
| A top-level `"links"` object **MAY** be used to specify URL templates that can be | ||
| used to formulate URLs for resources. This often allows API responses to be more |
There was a problem hiding this comment.
Here, I removed the phrase "according to their type" because it's incorrect—the templates are according to path—and added the next sentence to state the impetus for templates upfront.
There was a problem hiding this comment.
How about "resource representations" instead of "API responses"?
Trying to give an algorithm was out of the character of the spec, which doesn't give precise algorithms anywhere else. And it just made the description super messy (without even being fully specific enough to really implement directly as written.)
|
Hey @dgeb, Sorry it took me a bit to get back to this. I've updated my PR based on your feedback. |
|
|
||
| Each value in the `"links"` object may either be a string or an object. If a value is | ||
| a string, that string represents a URL template. If the value is an object, it must have | ||
| either an `"href"` key, a `"type"`key, or both; the `"href"` key holds a URL template |
There was a problem hiding this comment.
needs a space to break this up: "type"key
|
@ethanresnick thanks for updating this. I'm now 👍 on these changes, which really explain the top-level @steveklabnik @wycats what do you guys think? |
|
@dgeb Great! |
|
Related to #276 - we may want to reach a consensus on |
|
Thanks for your efforts here, @ethanresnick. Ultimately we ended up simplifying top-level links a great deal in #341. |
Addresses #250.