并且您已经为REST API的人员提供了这种结构,这个模式：

{
   "id": 12,"name":{
          "first":"Angie","last": "Smith","middle": "joy","maiden": "crowly",},"address": {
          "street": "1122 Something St.",..and so on...
    },... and so on
}

并且假设你有一个你的API的客户端(在这种情况下,一个全新的网络团队,这是一个远程和非常缺乏经验的人)来找你并说“嘿,我需要一个系统中所有唯一姓氏的列表”.

你会：

a)告诉那个人“好的,确定,好的名字已经是我们人员资源终点的一部分了.我们只能返回一个人员列表,它们只会给你name.last字段,你只能得到一个人每个不同的名字.存在的“.基本上只是给他们一个聚合的人群,以满足他们对数据库中人们基本上每个唯一姓氏的需求.

所以对于假设的url示例,他们只需要调用/people?fields=name.last?aggregate

b)哦,好的,我们只是为你创建一个特殊的端点,我们不知道那个资源或端点网址会是什么样子,但我们会给你这样的：

{
     "lastNames": {
            "name": "Anderson","name": "Alvertson",....etc.
      }
}

谁知道这甚至是什么资源,你甚至都没有这个名字.

而且你忘记了REST的所有好处,因为你的客户拒绝理解你有一个架构和惯例要维护,你通过你设置的资源向他们提供他们需要的东西,但他们认为他们必须遵守任何类型的资源模板是很奇怪的无论如何并期望你构建无限/无限的自定义资源,这些资源没有一致性或者甚至没有办法命名这些资源,因为它们将你的API与他们的应用程序相结合,他们希望你遵守他们认为你应该设计的任何合同.意思是他们觉得他们可以直接告诉你如何设计你的API并且你没有发言权！

而且你知道如果你只是放弃这一次并绕过你当前的REST资源,那就是“人”,他们很可能会希望你放弃你自己做过或想要用你的API做出的任何设计决定进入他们说他们不关心你的设计,但你是平台团队在公司范围内为消费创建这个API！

并且您知道您的API可能会被许多应用程序,其他服务甚至公众消费.

要么

c)只是说这个并且完全退出,因为不断尝试向他们解释REST的压力以及为什么你试图保持某些约定甚至是有意义的资源的简单概念并试图重用这些资源来获取相关数据,并找到一个更好的地方和团队合作,因为经过建设性和巧妙地试图告诉他们我们有一些我们在API上坚持的约定后,网络团队仍然觉得他们需要指定你的REST API设计100％,他们没有关于REST的线索,所以他们不关心你说什么…他们认为他们可以拥有API,即使是你和平台团队为公司建立它没有只有他们的消费,但可能是其他应用程序,服务,甚至将来向公众消费者公开此API.