后端接口中连续多个路径参数，这样设计接口是不是不太好

[darknoll]

比如 api/appX/{路径参数 1}/{路径参数 2}/{路径参数 3}

[zoharSoul]

github api 好像就有这种.

[SingeeKing]

连续三个太奇怪，但

api/appX/{路径参数 1}/描述 2/{路径参数 2}/ 这种还是挺常见的

[CodeCodeStudy]

不好，非常不直观

[no1xsyzy]

如果你有很明确的层级关系，这样一点问题都没有。但如果没有层级关系，这样就是在降低可维护性。

甚至还见过
.../{参数 1}/{参数 2}
和
.../{参数 1}/{参数 2}/False
是两个完全不同的接口，两个返回 json 字段重合的只有一个 id

[mikulch]

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

[Hstar]

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

[NotFoundEgg]

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

[KarmaWu]

改造成 api/appX?param1=xxx&param2=xxx 不好么

[Rache1]

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

[IvanLi127]

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

[chinvo]

filter 不用路径参数

别把伪静态那套风格带进 rest

[Vitta]

这种感觉好难受

[Symo]

事后写 access log 正则的时候会非常麻烦