Criteria for building hyperlinks

[awwright]

Right now, links that use variables that aren't defined are just cast as empty. There should be some way to specify a default value, or to depend on certain variables existing and skip the hyperlink if it doesn't exist.

For example, if there's a schema like

{ links: [
    { href:"/doc/{uuid}", rel:"self"  }
]
}

but multiple posts don't have a "uuid" property, then they all get the same URI of </post/> and all of a sudden we're saying multiple different posts are actually the "same". Oops!

This can sort of be done right now like so:

{ anyOf: [
   {
      required: ['uuid'],
      links: [ {href:'/doc/{uuid}', rel:'self'} ],
    }
]
}

... but this is bulky.

[handrews]

I have thoughts on this but they really need to be part of a much more comprehensive discussion of hyper-schema.

Also, you use doc in URIs in your JSON blobs but post in URIs elsewhere- I assume those are supposed to match.

This gets into how much hyper-schema should enforce about URI usage as opposed to description. It also really needs to get into the extended templating syntax which better allows distinguishing between required URI template elements and optional ones. URI templates do not make this distinction, and we should not impose such a distinction on them.

[handrews]

#108 addresses this thoroughly and shows ways to handle both schema-supplied defaults and user-supplied data.

[handrews]

@awwright does using an "hrefSchema" with "default" and/or "required" address this use case?

[handrews]

I'm pretty sure that the following things together solve this problem:

• The anyOf/required approach for only allowing links under certain conditions. This will become much more intuitive with if/then/else
• The ability to use required in hrefschema to require input.
• Both of these techniques can be used together to handle cases where you must have either instance data or client input, but need not have both.

While the required instance field technique is bulky, it is not complex, and I am not convinced the use case is common enough to warrant special syntax. Especially with if/then/else helping things.

Barring a new argument or clarity on how widespread the usage really is, I plan to close this assuming if/then/else is merged.

[handrews]

Note that we found another use case while working out #386, so more work is needed.