Affordance for rels other than self are not rendering.

resource.add(
    linkTo(methodOn(UserRestApi.class).getAll(pr.getPage(), pr.getSize())).withSelfRel()
        .andAffordance(afford(methodOn(UserRestApi.class).create(null, null))));

Renders the _templates as expected.

resource.add(
    linkTo(methodOn(UserRestApi.class).create(null, null)).withRel(CREATE)
        .andAffordance(afford(methodOn(UserRestApi.class).create(null, null))));

or

resource.add(Affordances.of(
        linkTo(methodOn(UserRestApi.class).create(null, null)).withRel(CREATE))
        .afford(HttpMethod.POST)
        .withInput(CreateUserCmd.class)
        .withName("create_user")
        .toLink());

Does not render any _templates section.

[ThanksForAllTheFish]

One “use case” to work with other links is practicality @odrotbohm. for instance, we have an API like

GET /events/{id}

{
  _links: {
     ...
     incidents: {
        href: /events/{id}/incident
     }
  }
}

for consumer it is more practical to already know at this point what it is possible on the list of incidents without having to retrieve the list. It just saves a call, so not a big deal imo, but one of those small things that might help adoptions.

I can see how enabling affordances on all links might causes other issues, like the need to come up with a convention to link template to link and having _templates being extremely large, so I am not sure the “use case” actually makes sense

[odrotbohm]

Lovely. Happy coding!