Allow to disable adding the HEAD and OPTIONS endpoints automatically in the Spring Converter

[marcelstoer]

Is your feature request related to one or multiple existing converters?
AFAICS only the Spring Converter is affected.

Describe the solution you'd like
I would like for the HikakuConfig to accept a feature flag that disables the implicit/automatic addition of HEAD and OPTIONS endpoints.

Additional context
I have never seen an OpenAPI contract in the wild that documented the HEAD and OPTIONS endpoints explicitly. Yet, if I don't I can't validate my implementation with hikaku. HikakuConfig#filters are not the correct approach IMO to solve this as I can't distinguish in my filter implementation whether a given HEAD/OPTIONS endpoint is an organic one or one that was added by hikaku.

[cc-jhr]

Hi @marcelstoer,

if I remember correctly spring used to offer HTTP methods for an endpoint in some special cases although those were not added to the internal object or something like that. Obviously hikaku should list all endpoints which are actually offered regardless of whether it is typical to document those or not. So in order to keep track of those hikaku adds them on its own.

This implicit addition of HTTP methods is only done in SpringConverter if I remember correctly. That alone is a reason for me to veto your request. HikakuConfig must not contain any converter specific options.

So to ignore HEAD/OPTIONS I'd say that the filter option is exactly what you want to use here. I'm not sure what you mean with "organic" endpoints. Do yo mean endpoints for which you manually defined HEAD/OPTIONS? In that case you could create a filter for all HEAD/OPTIONS endpoints except the manually created.

[marcelstoer]

Thanks for the feedback.

Obviously hikaku should list all endpoints which are actually offered

There's no way it would know for sure. It has access to my code but not to how I configure the frameworks & libraries my code runs with. Hence, insisting on adding "synthetic" endpoints which may or may not actually be available at runtime is opinionated (fine) and error-prone (not ok).

HikakuConfig must not contain any converter specific options.

I can understand that to a certain extent. The follow-up question, however, would then be: how do you configure the converters? Jackson did solve this nicely in their ObjectMapper configuration IIRC. Besides, if the flag were called something like GUESS_AUXILIARY_ENDPOINTS (or something along the lines thereof) you avoid tying it to a specific converter.

I'm not sure what you mean with "organic" endpoints. Do yo mean endpoints for which you manually defined HEAD/OPTIONS? In that case you could create a filter for all HEAD/OPTIONS endpoints except the manually created.

Yes, that's what I meant. Creating a custom filter would indeed work if I write the hikaku integration for my specific project. It falls short if, like in my case, I would write a hikaku integration library that dozens of projects should be able to integrate without any extra configuration.