REST API improvement proposals

Hi all! I create this thread to discuss improvement proposals for the rest api functionality. I’ll start with 2 proposals:

  1. Basic authentication for remote rest services.

Problem: As you can see in the RemoteRestServiceRunner, currently it doesn’t support basic authentication.

// TODO/FUTURE: other options for remote authentication with headers/etc? a big limitation here, needs to be in parameters for now

Solution: I propose to add 2 parameters basicUser and basicPassword that the RemoteRestServiceRunner will automatically use as basic authentication. Add this below line 47(first line here):

        RestClient rc = eci.serviceFacade.rest().method(method)
        if (parameters.basicUser && parameters.basicPassword)
            rc.basicAuth(parameters.basicUser as String, parameters.basicPassword as String)
        parameters.remove("basicUser")
        parameters.remove("basicPassword")

And then when you define the service you do something like this:

    <service verb="send" noun="RemoteRestCallWithBasicAuth" type="remote-rest"
             method="POST" location="https://example.com">
        <in-parameters>
            <parameter name="basicUser"/>
            <parameter name="basicPassword"/>
             ........
            <parameter name="body"/>
        </in-parameters>
        <out-parameters>
            <parameter name="response" type="Map"/>
        </out-parameters>
    </service>
  1. Relax parsing of header values in jetty 12.

Problem: If we get a response with a header of this type: Nel: {"report_to":"cf-nel","success_fraction":0.0,"max_age":604800} we get an error like this: 400: BAD_QUOTES_IN_TOKEN. That is because of jetty validation that happens in RestClient line 425:

curList.addAll(Arrays.asList(hdr.getValues()));

Solution: My proposal is to replace the line with this:

curList.add(hdr.getValue());

Because org.eclipse.jetty.http.HttpField.getValues() performs the validation, but org.eclipse.jetty.http.HttpField.getValue() does not, it just returns the raw value. And then if clients want to perform some validation or comma splitting values they can do it themselves and control the error throwing.

If any of these proposals are accepted I am ready to submit pull requests.

This would break calling foreign REST services with RestClient that use basicUser or basicPassword as parameters.

Well yes, whatever names we find for the parameters they are still going to break the foreign rest body. In the current implementation I don’t see another way to pass headers, only as parameters.