@EndpointDisabled can be used on methods

[farnetto]

Description

@EndpointDisabled currently "provides the ability to conditionally enable [i.e. disable] a JAX-RS Resource class at runtime based on the value of a property."

I would like to use this annotation or a similar one to disable specific methods (in Rest Data Panache https://quarkus.io/guides/rest-data-panache#using-a-runtime-property) at runtime based on a property.

My use case is, I use the state-changing PUT, POST and DELETE methods in tests, but want to disable them for security reasons in production and still be able to use the GET methods in production to query the data.

Implementation ideas

Currently the annotation is @Target({ElementType.TYPE}) but should ideally be also ElementType.METHOD.

[farnetto]

Alternatively one could extend the exposed attribute @MethodProperties to support a runtime property the way @EndpointDisabled supports a runtime property.

[mschorsch]

As an alternative you could use build profiles e.g.

   @DELETE
   @IfBuildProfile("test")
    public void deleteSomething () {
        // ...
    }

[farnetto]

but I want a toggle for runtime not build time...

[gsmet]

I think the requirement makes sense. I also wonder if it could be a good first issue if someone from the team provided a bit more details about how it could be implemented.

I would expect most of the changes to be done in EndpointIndexer.
My main question is if we should adjust the current isDisabledCreator to target a method (and then default to the behavior of the enclosing class) or if we add another Function to handle the methods.

@FroMage @geoand WDYT?

[geoand]

What OP is asking for though is to have the methods disabled with a runtime configuration property.

I don't remember how the annotation works, so I would have to look at the code again

[FroMage]

Makes sense to extend its granularity from class to methods, yes.

[farnetto]

I'd love to try implementing it myself - as a first issue as @gsmet says.

[geoand]

Feel free!

[geoand]

My main question is if we should adjust the current isDisabledCreator to target a method (and then default to the behavior of the enclosing class) or if we add another Function to handle the methods

I think adjusting the existing one is probably better