10 | 将模型实现为RESTful API（上）

URI是不是太长的问题，让我想起了代码层面违反迪米特法则的情况。它们的共同点是暴露了一个层级结构。 如果说因为URI体现的是稳定的业务模型，所以暴露层级是合理的，那么是不是在代码层面，如果对象层级符合模型，也不需要在意迪米特法则呢？

HTTP常用的方法就get put post delete patch, 实际业务中对一个资源对象的操作可能超过5种，api的body的报文结构如何设计，才能避免api退化成混合了rpc风格的api呢？如修改文章内容，可能修改文章的body，也可能是修改文章标题,都用put, 请求的body怎么设计更符合面向对象的范式呢？

订阅专栏跟送朋友专栏这两个API，HTTP 方法和 URI是一样的，无法区分，一般来说，当前用户的身份都会通过HTTP cookie进行鉴权，所以建议订阅专栏的URI直接简化为/subscriptions，送朋友专栏的URI为/users/{friend_id}/subscriptions，这两个API都由User-Subscriptions聚合来实现

读者Oops的问题，我在下一节中还是没有找到答案，这也是我一直没有在项目中使用restful api的原因，对一个聚合的下某个实体的操作（系统用例：修改、发布、撤回、审批、拒绝、同意..）大多数情况下会超过get put post delete put这五种，尤其是在复杂的业务系统中。看遍全网所有讲restful api的文章，均没有讲到这点，不知道是因为他们的业务简单，还是他们根本就没有在真实的业务系统中实践过。还请作者能再详细的分析一下这个问题，或者给出一个解法

哇，原来restful api与rpc有这样的区别，与rpc相比还真没看出restful的好，在公司内部也有大量的讨论，主要restful api以资源为重点，不能出现动词，而HTTP中的几个动词不足以覆盖业务行为需求 现在看主要是对rest背后的原理没有明白，比如哪个主哪个次，像/schools/students,还是/students/schools,总是分不清，常常争吵，以文中所讲用领域模型来理解，并着重在聚合关系上，那就清晰得多，与角色目标实体建模法相得益彰 但对于to b项目系统筛选器的筛选项达到百个，各种组合，搜索api使用http get以过滤器的方式增加参数，就会超出http限制，不得不使用post，理解为创建了一个搜索任务，但总感觉别扭

本章 REST 希望开发者面向资源编程，网络交互设计的重心放在抽象交互需要用到哪些资源上，而不是抽象系统该有哪些行为（服务）上。所以要求采用统一接口，从约束开发者的行为来逼迫开发则尝试提炼资源模型的思考。（与要求领域服务要加动词异曲同工） 课后题： 实现倒是不难，但我觉得不该这么做。 实现： 提供大而全的数据结构，客户端与服务交互时上次客户端的类型，服务端通过识别类型提供对应客户端需要的数据内容，并将这些内容填充在大而全的数据结构上。做到多端多面，每种端都只需要关心这个大而全的数据结构中自己关心的部分。（因为数据结构上不关心的部分不会有数据填充，所以也没有冗余数据带来的性能下降） 不应该这么做： 1.RESTful 架构风格的核心是开放性和扩展性。我认为开发性的重心是放在产品侧的，讲究的是我抽象一个功能，可以给任何具象的端或则行业来用，我不感知你们的差异，也就是我只满足共性部分。所以不该去做量身定做的事。量身定做的事由各端各行业自行扩展。 2.旁外化：开放性的对立面，比如说智慧供应链。我认为智慧供应链的智慧是站在需求端的，以满足所有类型的供应链需求，做到千链千面。

重读疑惑： 先说结论： 仅看极客2c的App，聚合应该是Column，而不是Author。 论据： 1.用户查看资源的核心目标是 Column。 2.用户付费购买的核心单元是 Column。 3.用户没有购买 Author的诉求，仅是通过 Author 查看其下的 Column。 类比: Column就像电商网站的商品， 计算机基础/后端/前端/产品 这些就像是类目, 而Author就像是品牌。有些场景我需要查看某品牌下的商品，有些场景我需要查看商品是属于哪个品牌的，但我不会购买品牌， 品牌只是商品关于信誉这个维度的补充信息。作者之于专栏也是如此。 旁外话: 仅看看极客2b的App，以Author为聚合就没毛病。再次类比电商，Column依旧是商品，但Author这时候就是具体的供应商。我只会和供应商谈合作，签合同，做结算，而不是商品。

没搞明白角色在api中的作用，就比如那个admin_id，在api中如何体现

内容理解： 1、从行为角度设计的 API，是 RPC 风格的 API，这种 RPC 风格API的方法名不是来自于领域对象，入参和出参与领域模型无光，因此它不是领域模型驱动的API设计。不过目前大部分用的是这种风格的 API ，见名知意更容易理解，比如用户注册，用register而不是POST /users。 2、RESTful API 是作为实现领域驱动 API 设计的最佳选择，它易于被其他系统整合，没有什么其它数据风格 API 可选。 3、将模型映射为 RESTful API，a.通过 URI 表示领域模型；b.根据 URI 设计 API。只有前面的领域模型没有问题，这一步很简单。 思考题： 使用GraphQL？

如果出现跨多个聚合的行为URI该如何设计呢？