[Feature][3.3] Triple protocol support multi arguments

[AlbumenJ]

Pre-check

• [X] I am sure that all the content I provide is in English.

Search before asking

• [X] I had searched in the issues and found no similar feature requirement.

Apache Dubbo Component

Java SDK (apache/dubbo)

Descriptions

Triple protocol support multi arguments in none-annotation mode

Interface:

public interface GreetingsService {
    String sayHi(String name, String message);
}

Example requests:

1. using array

curl \
    --header "Content-Type: application/json" \
    --data '["Dubbo","hello"]' \
    http://localhost:50052/org.apache.dubbo.samples.tri.unary.GreetingsService/sayHi/

2. using map

curl \
    --header "Content-Type: application/json" \
    --data '{"name":"Dubbo","message":"hello"}' \
    http://localhost:50052/org.apache.dubbo.samples.tri.unary.GreetingsService/sayHi/

Related issues

No response

Are you willing to submit a pull request to fix on your own?

• [ ] Yes I am willing to submit a pull request on my own!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[finefuture]

I'm interested. Please assign it to me.

[oxsean]

@finefuture I'm currently working on this, and I'm make a tasklist for rest, if you're interest on it, I can assign some to you.

[finefuture]

@finefuture I'm currently working on this, and I'm make a tasklist for rest, if you're interest on it, I can assign some to you.

Okay, please assign some to me.

[Chenjp]

@AlbumenJ request payload will be determined by interface argument name, is it a good idea?

[AlbumenJ]

@AlbumenJ request payload will be determined by interface argument name, is it a good idea?

This is as expected

[Chenjp]

@AlbumenJ request payload will be determined by interface argument name, is it a good idea?

This is as expected

Assume another composite parameter exist:

public class CompositeBean implements Serializable {
  private String name;
  private String code;
  .... 
}
public interface GreetingsService {
  String sayHi3(String name, String message, CompositeBean source); 
}

I dont know what request should be.

[AlbumenJ]

@AlbumenJ request payload will be determined by interface argument name, is it a good idea?

This is as expected

Assume another composite parameter exist:

public class CompositeBean implements Serializable {
  private String name;
  private String code;
  .... 
}
public interface GreetingsService {
  String sayHi3(String name, String message, CompositeBean source); 
}

I dont know what request should be.

["testName", "testMessage", {"name":"subName", "code": "subCode"}]

[Chenjp]

@AlbumenJ I have another question, does triple protocol allow method overload currently?

public interface GreetingsService {
  String sayHi3(String name, String message, CompositeBean source); 
  String sayHi3(String name, String message, SourceBean source);
}

[AlbumenJ]

@AlbumenJ I have another question, does triple protocol allow method overload currently?

public interface GreetingsService {
  String sayHi3(String name, String message, CompositeBean source); 
  String sayHi3(String name, String message, SourceBean source);
}

For Triple in wrapper mode, we support. For Triple in plain http or grpc mode, we don't support.

[Chenjp]

@AlbumenJ I have another question, does triple protocol allow method overload currently?

public interface GreetingsService {
  String sayHi3(String name, String message, CompositeBean source); 
  String sayHi3(String name, String message, SourceBean source);
}

For Triple in wrapper mode, we support. For Triple in plain http or grpc mode, we don't support.

Since dubbo support multi-protocols and different protocols have different constraints. It's better to ensure semantic consistency, make each Service protocol-insensitive. I recommend removing method overload support for all protocols.

[AlbumenJ]

@AlbumenJ I have another question, does triple protocol allow method overload currently?

public interface GreetingsService {
  String sayHi3(String name, String message, CompositeBean source); 
  String sayHi3(String name, String message, SourceBean source);
}

For Triple in wrapper mode, we support. For Triple in plain http or grpc mode, we don't support.

Since dubbo support multi-protocols and different protocols have different constraints. It's better to ensure semantic consistency, make each Service protocol-insensitive. I recommend removing method overload support for all protocols.

That is a hope. Only a hope. Really really really hard~

[oxsean]

    def "override mapping test"() {
        given:
            def request = new TestRequest(path: path)
        expect:
            runner.run(request, String.class) == output
        where:
            path                          | output
            '/say?name=sam&count=2'       | '2'
            '/say?name=sam'               | '1'
            '/say~SL'                     | '2'
            '/say~S'                      | '1'
            '/say~S?name=sam&count=2'     | '1'
            '/say~S.yml?name=sam&count=2' | '1'
    }

    String say(String name, Long count)

    String say(String name)

In the latest REST Triple, support method override has been added by passing the method signature abbreviation.