请教一下大佬们怎么设计接口

[MakHoCheung]

是面向业务设计接口还是面向资源设计接口

比如一个订单表包含有地址信息，修改地址这么一个需求，设计接口一般是 /updateAddress 还是 /updateOrder 呢，如果用 /updateOrder 的话后续更新订单其他信息也可以复用这个接口，但是更新订单信息可能当前业务只开放修改部分信息，所以接口里面做校验的逻辑就复杂了很多，如果用 /updateAddress 的话接口会越来越多，也增加测试的工作量

大佬们有何见解

[MakHoCheung]

@fivesmallq 我这边举的例子就是“用户有临时修改这个订单地址的时候”，不过我也倾向你这种“put /orders/:orderId/address” 而不是“ put /orders/:orderId/”

[fivesmallq]

推荐 2 个 api 设计的指南，我会经常参考 google 的 https://cloud.google.com/apis/design?hl=zh-cn

微软 azure 的 https://docs.microsoft.com/zh-cn/azure/architecture/best-practices/api-design

另外有些场景想不太明白也会参考 https://docs.github.com/en/rest/repos/repos 和 https://docs.digitalocean.com/reference/api/api-reference/#operation/list_deployments

总是看到有人说 RESTful 不好用，复杂场景搞不定，自己思考过，参考过好的设计吗？

[lldld]

这个我是分两层的.
数据表相关的用资源的方式暴露内部接口;
业务相关的用前端需要的逻辑组合内部接口, 添加逻辑, 一般都是 POST, 比如问题中这个, 接口名字可能是 /order/address/update, /updateOrderAddress

[MakHoCheung]

@fivesmallq 多谢