比如 api/appX/{路径参数 1}/{路径大带宽服务器参数 2}/{路径参数 3}

github api 好像就有这种.

连续三个太奇怪，但
api/appX/{路径参数 1}/描述 2/{路径参数 2}/ 这种还是挺常见的

不好，非常不直观

如果你有很明确的层级关系，这样一点问题都没有。但如果没有层级关系，这样就是在降低可维护性。
甚至还见过
.../{参数 1}/{参数 2}
和
.../{参数 1}/{参数 2}/False
是两个完全不同的接口，两个返回 json 字段重合的只有一个 id

看你多大的项目了。一般的项目不要要求太严格了。。

如果你的路径参数是语义化的，如 api/appX/earth/asia/china，我觉得还行，如果是 api/appX/3/5/7，那就太垃圾了

连续 2 个 我感觉看着都很难受

改造成 api/appX?param1=xxx¶m2=xxx 不好么

一般 rest 风格，最好参数前面要有实体名字的，如果是 filter 参数的话，还是建议使用 GET 或者 POST 的 payload 传递，而不是这种强行拼接

具体问题具体分析，得看这参数有没有层级关系，没有的话大概率不合适，有的话那还成，当然。。。能一步到位的话应该考虑直接用最后一个参数来获取数据。

filter 不用路径参数
别把伪静态那套风格带进 rest