Affordances using HTTP GET excluded from the output

[oliverhenlich]

trafficstars

This is in reference to https://stackoverflow.com/questions/68903785/spring-hateoas-hal-forms-does-not-add-current-get-endpoint-to-the-template-secti and I just ran into the same problem.

The spring docu [1], code [2] & spec [3] don't line up. Not sure if it's a bug or just a documentation error.

The spec seems to say GET should be allowed [3]

The HTTP method the client SHOULD use when the service request. Any valid HTTP method is allowed. This is a REQUIRED element. If the value is empty or is not understood by the client, the value MUST be treated as an HTTP GET.

[Ickbinet]

This would be very useful because a HalForm has more information than a templated URL, e.g. the client could create a better search form for this Affordance.

[oliverhenlich]

Any update on this? One reason we are exploring this is to use it to occupy the "default" afforance slot so that our actions on the resource can all have explicit and meaningful names.

[oliverhenlich]

Hi @odrotbohm,

I see your two commits above but am not sure how they relate to my issue?

Is there a possibility to allow GET affordances? That is to remove this line https://github.com/spring-projects/spring-hateoas/blob/3d7458b5f6912c6ccd553cda8345ca6c62826506/src/main/java/org/springframework/hateoas/mediatype/hal/forms/HalFormsTemplateBuilder.java#L66

Should I submit a PR for this?

[oliverhenlich]

I'm also confused by the integration tests where there is code like this (creating affordances for GET methods).

@GetMapping("/employees")
public CollectionModel<EntityModel<Employee>> all() {
...
		Link selfLink = linkTo(controller.all()).withSelfRel() //
				.andAffordance(afford(controller.newEmployee(null))) //
				.andAffordance(afford(controller.search(null, null)));
...
}

@GetMapping("/employees/search")
public CollectionModel<EntityModel<Employee>> search(@RequestParam(value = "name", required = false) String name,

[odrotbohm]

The commit references were a mistake. I meant to reference #1696.

Regarding the support for GET, it is unfortunately not as simple as removing the guard as – as you also discovered in your PR – breaks existing applications as they'd all of a sudden see templates created for the self link affordances get added to, usually. Rest assured this is being thought through currently but there's a lot of moving parts to be considered so that we're not going to get to a solution for this before the 1.4 release. It's on the radar for 1.5 / 2.0 though.

[oliverhenlich]

Thanks for the response @odrotbohm. Much appreciated. I'm having to work around it for now (I'm pretty sure the team won't like it though haha).

The root cause for me even looking at this is the strange requirement that the first template must be called the "default" template. I know there are other issues that have been raised about that and you've raised it with the spec author too. It's that feature I'm trying to work around by occupying the default slot with a GET template that just provides some metadata about the resource.

[Ickbinet]

Could be a HalFormsConfiguration option to allow GET with a HALFORM.

[damienhollis]

@odrotbohm - just wondering whether this made it into 2.0 or is still on the roadmap?

[mbimbij]

+1 on the issue. Even in this example of the reference documentation, the one affordance on GET method doesn't show up, which got me super confused as i was following along