Github user zentol commented on the issue:

    https://github.com/apache/flink/pull/4569
  
    @tillrohrmann I've addressed most of your comments.
    
    I have implemented the `HandlerResponse` as you suggested (casting option) 
for now, and include all query parameter as a list.
    
    ## Unaddressed comments:
    * Cleaner shutdown of netty components in server
    * Closing of netty connection (_somewhere_)
    * RestEndpointITCase: client/server shutdown in finally block
    
    ##
    
    ## Parameter Rework
    * Remove the `ParameterMapper` and related code
    * `MessageHeaders` now has a generic `MessageParameters` argument
    * `MessageParameters` is an abstract class that contains a collection of 
`MessageParameter`s that are suppported for the given request, and provides a 
utiltiy method for checking whether these parameters were resolved
    * `MessageParameter` is also an abstract class, that defines the key, 
accepts a value (i.e. resolve the parameter), defines whether the parameter is 
mandatory/optional and whether it is a query/path parameter
    
    ### Usage
    
    Let's say we want to have a request for getting the details of a job, with 
a path parameter for the job id :
    
    We first define a path parameter for the job id (or reuse an existing one!):
    
    ```
    public final class JobIDPathParameter extends MessagePathParameter {
        public JobIDPathParameter () {
                super("jobid", MessageParameterRequisiteness.MANDATORY);
        }
    
        public void resolve(JobID jobID) {
                super.resolve(jobID.toString());
        }
    }
    ```
    
    We then define the sum of all parameters for the request:
    
    ```
    public final class JobDetailsParameters extends MessageParameters {
        private final JobIDPathParameter jobID= new JobIDPathParameter ();
    
        @Override
        public Collection<MessageParameter> getParameters() {
                return Collections.singleton(jobID);
        }
    }
    ```
    
    And finally, we include it in the JobDetailsHeaders:
    ```
    public final class JobDetailsHeaders extends 
MessageHeaders<JobDetailsRequest, JobDetailsResponse, 
JobDetailsMessageParameters> {
    ...
    ```
    
    The usage for the client would then look like this:
    ```
    JobID jobID = ...
    JobDetailsParameters parameters = headers.getUnresolvedParameters();
    JobDetailsParameters.jobID.resolve(jobID);
    client.sendRequest(headers, parameters, request);
    ```



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to