We need dubbo-proxy can handle with form post or queryString about dubbo-proxy HOT 8 OPEN

I agree with you.
一、对与原来设计的请求格式

{application Name}/​{Interface name}?version={version}&group={group}

我觉得可以把version和group放到request header里面去，这样就可以不干扰普通的get请求。

二、 对与原来设计的请求参数

{
"methodName" : "sayHello",
"paramTypes" : ["org.apache.dubbo.demo.model.User"],
"paramValues": [
{
"id": 23,
"username": "testUser"
}
]
}

1. 把methodName也放到请求路径上去；
2. 把paramTypes去掉，没有必要，json是松散的，解析后能对应上，就作为参数处理，对应不上，就为空；
   在请求头 增加参数解析与接口实际参数的匹配方式，可以做成3种等级：严格（每一个参数的名称和类型都要对应上）、较松散（参数的名称可以不完全一致，但类型必须一致）、松散（参数的名称和类型都可以不一致，全部对应不上，就全是空）
3. 最后，就只剩下真正的参数了，完全符合网关的要求了。

为了实现上面说的效果，不使用类似于过滤器的东西，好像是没有办法实现的吧

from dubbo-proxy.

I agree with you.
一、对与原来设计的请求格式

{application Name}/​{Interface name}?version={version}&group={group}

我觉得可以把version和group放到request header里面去，这样就可以不干扰普通的get请求。

二、 对与原来设计的请求参数

{
"methodName" : "sayHello",
"paramTypes" : ["org.apache.dubbo.demo.model.User"],
"paramValues": [
{
"id": 23,
"username": "testUser"
}
]
}

1. 把methodName也放到请求路径上去；
2. 把paramTypes去掉，没有必要，json是松散的，解析后能对应上，就作为参数处理，对应不上，就为空；
   在请求头 增加参数解析与接口实际参数的匹配方式，可以做成3种等级：严格（每一个参数的名称和类型都要对应上）、较松散（参数的名称可以不完全一致，但类型必须一致）、松散（参数的名称和类型都可以不一致，全部对应不上，就全是空）
3. 最后，就只剩下真正的参数了，完全符合网关的要求了。

为了实现上面说的效果，不使用类似于过滤器的东西，好像是没有办法实现的吧

From me , I just want make it compatible with the old format.
So I just add code like this

  private Splitter queryStringSplitter = Splitter.on(",").trimResults().omitEmptyStrings();

  
 if (params.containsKey("methodName")) {
                methodName = params.get("methodName").get(0);
            }
            if (params.containsKey("paramTypes")) {
                @SuppressWarnings("UnstableApiUsage") List<String> paramTypesList = queryStringSplitter.splitToList(params.get("paramTypes").get(0));
                if (!paramTypesList.isEmpty()) {
                    paramTypes = paramTypesList.toArray(new String[]{});
                }
            }
  if (methodName != null && serviceDefinition.getMethodName() == null) {
                serviceDefinition.setMethodName(methodName);
            }
            if (paramTypes != null && serviceDefinition.getParamTypes() == null) {
                serviceDefinition.setParamTypes(paramTypes);
            }

from dubbo-proxy.

paramTypes also need just because dubbo 2.6.x can not know the type

from dubbo-proxy.

@hbwhypw 如果必须用dubbo本身提供的泛化处理，其实这个是没办法处理的，但是如果要传递 xxx.xxx.bean， 这样其实是不友好的，除非我们不使用她的dubbo泛化，直接跳过这部分，到目标机器上

举个例子
正常的dubbo处理.

user  ---> nginx ---> toncat#controller ----> 调用dubbo ---> dubbo#service处理

调用dubbo 这一步是tcp的，如果可以转化成 http 的就可以达到你这个效果了，其实就是直接将dubbo请求转化成http请求了，只是不经过controller，直接让service对她进行处理，这个是可以做到的，这样一来，前端直接发送所需要的参数即可，其他的全都不需要了.

from dubbo-proxy.

@hbwhypw 如果必须用dubbo本身提供的泛化处理，其实这个是没办法处理的，但是如果要传递 xxx.xxx.bean， 这样其实是不友好的，除非我们不使用她的dubbo泛化，直接跳过这部分，到目标机器上

举个例子
正常的dubbo处理.

user  ---> nginx ---> toncat#controller ----> 调用dubbo ---> dubbo#service处理

调用dubbo 这一步是tcp的，如果可以转化成 http 的就可以达到你这个效果了，其实就是直接将dubbo请求转化成http请求了，只是不经过controller，直接让service对她进行处理，这个是可以做到的，这样一来，前端直接发送所需要的参数即可，其他的全都不需要了.

可以做网关录入啊 不需要手动写这个controller
目前我们会就是把这个部分通过录入固定参数的方式实现了

from dubbo-proxy.

@qixiaobo 一般dubbo转http主要是网关用的，也不是录入固定参数吧，我的实现就是类似与 Zuul ， 提供一个Servlet来处理. 然后借助Spring，直接invoke service，不经过controller。 可以这么说，对于业务其实都是无感知的。

from dubbo-proxy.

录入固定参数的意思把service这些名称录入进去 可以屏蔽这些 只需要关注参数和返回值

from dubbo-proxy.

可以试试，grpc-dubbo-proxy 直接封装为grpc服务，调用路径可以做到
nginx-> grpc-dubbo-proxy-> dubbo。

from dubbo-proxy.