spring-hateoas
spring-hateoas copied to clipboard
spring-projects
Add a contentType property to the HAL-FORMS template element automatically or by hand
@gregturn asked me on Gitter to create this issue.
We talked about how one could add a 'contentType' property to a HAL-FORMS template element, either automagically or by hand.
@ingogriebsch Trying to understand HAL-FORMS in more detail and currently wondering how I can control to add a 'contentType' to a 'template'.
@gregturn And we haven't (yet) coded support to populate the rest of the HAL-FORMS fields. Spring HATEAOS has sought to capture a vendor neutral format that can be serialized into multiple media types. That avoids having to bake media type awareness into your application. However, when it comes to media type specifics, we may need to consider adding, perhaps, annotations to fill in the bits like contentType. For example, would a @HalForms annotation be useful on a domain object to flesh those details out? Is that the best approach?
@ingogriebsch I expected that the Introspection mechanism checks if the @RequestMapping on the @RestController has defined a 'consumes' or 'produces' and adds a 'contentType' element to the input and/or output without any further ado. I also checked the Affordances API if it allows me to define a contentType through the PayloadMetadata. Another option would be some kind of additional information on the object which represents the payload (maybe through a @HalForms as you mentioned) but it could be hard to add an annotation on every type of payload one wants to use (how about a MultipartFile for example?).
@gregturn That's a good idea. If you captured the consumes/produces idea into an issue, we can pursue that.
Feel free to change/cleanup this ticket as you wish. If I can help in some way, please let me know! :)
Original discussion starts here: https://gitter.im/spring-projects/spring-hateoas?at=5d876bbac77f285fb1c25f86
I am torn on this one as the spec currently defines only application/json and application/x-www-form-urlencoded as supported media types, there's little value in exposing the contentType property as application/json is the only value that makes sense for now.
Does it make sense to ask @mamund to open up that clause, so that e.g. custom media type declarations could be used at least?
Given the encType for an HTML5 <form> is not confined to these two types, I agree that widening the HAL-FORMS spec to allow other media types should be possible.
I don't have any problem with this. As long as it is a non breaking change.
On Thu, Oct 31, 2019, 11:58 Greg Turnquist [email protected] wrote:
Given the encType for an HTML5
Thanks @mamund! I opened https://github.com/mamund/hal-forms/issues/30 to track this in the spec.
I've coded a patch that adds incoming and outgoing media types to the AffordanceModelFactory and AffordanceBuilder API. SpringAffordanceBuilder is able to use this to collection consumes/produces details from Spring MVC/WebFlux methods and embed them in the affordance details.
HAL-FORMS can now look up incoming media types and use it to populate contentType. Other media types are free to leverage this additional meta data.
The changes are as backwards compatible as possible, with deprecations in place, which we should be able to then remove in the 1.2 time frame.
The test controller have been updated to demonstrate this, but it's debatable if we want to keep those changes. We may wish to have a separate WebFluxEmployeeController/WebMvcEmployeeController that exercises and verifies this feature.
Feedback welcome.
@odrotbohm the HAL-FORMS spec has been expanded such that other media types may be plugged into the contentType field. I'll check the status of the branch involving this work and see if it can't be cleaned up and reviewed.