Yes, it's somewhat of an anti pattern.

The object oriented way of "deciding what to call" is to leverage polymorphisem.

Your code looks like Java. Java enums can have methods. Just call the enum Operation, with a method process(), like this:

enum ProcessingType { CONFABULATION{ process(Data data) { //logic goes here } }, RETICULATION{ ... }, SPLICING { ... }; abstract process(Data data); } 

Then your web service method can do this:

@Mapping("/operation/{processingType}") void process(@RequestBody Data data, @RequestParameter Operation operation) { operation.process(data); } 

And the Service class becomes unnecessary. And you can add new operations in only one place.

However, in languages that don't have enums with methods that can be automatically mapped from controller methods, the easiest way might be still the switching logic in its own method.

Yes, it's somewhat of an anti pattern.

The object oriented way of "deciding what to call" is to leverage polymorphism.

Your code looks like Java. Java enums can have methods. Just call the enum Operation, with a method process(), like this:

enum ProcessingType { CONFABULATION{ process(Data data) { //logic goes here } }, RETICULATION{ ... }, SPLICING { ... }; abstract process(Data data); } 

Then your web service method can do this:

@Mapping("/operation/{processingType}") void process(@RequestBody Data data, @RequestParameter Operation operation) { operation.process(data); } 

And the Service class becomes unnecessary. And you can add new operations in only one place.

However, in languages that don't have enums with methods that can be automatically mapped from controller methods, the easiest way might be still the switching logic in its own method.