"By default, an element that causes a request will include its value if it has one. If the element is a form it will include the values of all inputs within it." https://htmx.org/docs/#parameters
Even after enabling the DuplicateRecordFields, NoFieldSelectors and OverloadedRecordDot triad, record update for ambiguous fields remains a pain, often alleviated with lens libraries like "generic-lens".
I might be splitting hairs about the semantics of #HTTP PUT, but there seems to be a slight contradiction in #rfc9110
On one hand, a GET after a PUT should return the exact representation that was set by the PUT.
On the other hand, a PUT "might also cause links to be added between the related resources" which seems to say that the representation might be enriched with extra links.
I generally prefer package-by-feature. But: I also like #API-first development (generating controller interfaces using #OpenAPI Generator for example) and I feel it clashes a little with the package-by-feature approach, because you generate an entire "layer" (the controllers) in one go, and all the results tend to be put in the same package. https://openapi-generator.tech/docs/generators/spring/
How to resolve this apparent tension?
@blaue_Fledermaus Rel8 is more like a DSL for building queries. ORMs typically support returning object graphs, but handle a lot of other things as well: caching, lazy loading, dirty tracking, etc. They might also trigger multiple queries behind the scenes.
So the particularity of Rel8 is that it generates stand-alone queries and yet it's able to reconstruct hierarchical data from the results. I'm not sure what's the exact mechanism though... Rel8-generated queries are quite scary to look at!
