API Level Request Validation

[Snarr]

In the LittleHorse Server, we often validate request fields at the #process method level, which runs after a record has been forwarded to the CommandProcessor. However, often times a request can be rejected earlier at the API level.

Example

message RunWfRequest {
  string wf_spec_name = 1;
  optional int32 major_version = 2;
  optional int32 revision = 3;
  map<string, VariableValue> variables = 4;
  optional string id = 5;
  optional WfRunId parent_wf_run_id = 6;
}

The above protobuf message defines a request for RPC RunWf on the LittleHorse Server. While not specified in the protobuf contract (because required is not recommended in proto3), a RunWfRequest requires a wf_spec_name to function. We can save time and resources by validating that a RunWfRequest sent to the server has a valid wf_spec_name at the API level, and rejecting any requests that don't.

API Level Validation

@Override
@Authorize(resources = ACLResource.ACL_WORKFLOW, actions = ACLAction.RUN)
public void runWf(RunWfRequest req, StreamObserver<WfRun> ctx) {
    if (Strings.isNullOrEmpty(req.getWfSpecName())) {
        throw new LHApiException(Status.INVALID_ARGUMENT, "Missing required argument 'wf_spec_name'");
    }
    ...
}

Discussion

Here are some discussion questions to get the conversation started:

1. Do we need to perform the validation twice, once at the API level and once at the processor level? If so, why?
2. What other LittleHorse Server RPC services can we apply this "API Level" validation to?
3. Should "API Level" validations introspect on objects and resources within the LittleHorse Server? Ex: Check if the wf_spec_name exists within the server, reject unknown wf_spec_names at the API level
4. Is there any way to co-locate the validation logic between the API level and the processor level? As of PR fix(server): Reject invalid wf_run_id in RunWfRequest #1321, the validation logic is split between the two levels and needs to be updated in both places when changes are made.