- Root - router1 - category1 - interface1 - prefix1 - prefix2 - interface2 - prefix21 - category2 - router2 - category21 上面是结构. api 的设计 [ol]*/api/routers//interfaces*/api/interfaces/?router-id= 哪种更好? [/ol] 如果下一层 [ol]*/api/routers//interfaces//prefixes*/api/prefixes?router_id=1&interface_id=2 [/ol] 谢谢. API, router_id, Interfaces, prefixes
router_id 作为一种资源，出现在路径中或参数中都是符合 RESTful API 的设计规范的。 很多公司会选择同时支持两种用法；你也可以问一问前端同学的喜好，规范一种用法。 通常国外的开发者会倾向于把资源放在路径中，国内的开发者会倾向于把资源放在参数中。这是两种不同的理念，如果这个接口日后的开发迭代会经常变动函数签名，那么把资源放在参数中可能更方便；如果你的资源只有有限的几种，那么把资源放在路径中更合理。
按照 restful 规范,很显然是第一种. 参数拼接很显然是不符合的。 当然，实际中，第二种写起来要更灵活一些，你可以随意拼接任何参数。 但是规范的目的本来就不是为了方便，规范是为了统一，让 URL 看起来更加清晰，避免歧义。 比如说，在大家都熟知规范的情况下，你给我*/api/routers//interfaces ， 我不需要查文档就明白，这肯定是一个 interfaces 的列表 并且， 我想获取某个 routers 很显然就是*/api/routers/， 我想获取 routers 的列表就是*/api/routers 但是你要给我 */api/interfaces/?router-id=[i] ， 我完全不知道该如何获取 routers 的列表和单个 routers 。 这就是规范的意义，大家都遵守就减少沟通成本。 最后，restful 按理说不要出现复数， 资源写成 router ，interface 就可以了
