Question

让我们假设您正在领导开发新的REST API。格林菲尔德。

您已经为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字段返回，你只会得到一个人的每个不同的名字。存在“。基本上只是给他们一个聚合的人群，以满足他们对数据库中人们基本上每个唯一姓氏的需求。

因此，对于假设的网址示例，他们只需拨打/people?fields=name.last?aggregate

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

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

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

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

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

而且您知道您的API可能会被许多应用，其他服务甚至公众消费。

或

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

Answer 1

根据我的经验，这是REST（或任何其他）API提供商与Web，移动设备，无论API消费者之间合作中最常见的问题。

我总是尽可能地遵守规则并强迫消费者接受我的约定和架构。为什么？由于您提到的原因，其中哪一项至关重要：您的API有一天可能会公开，每当消费者需要向粉红色裙子显示用户时，您就无法引入新的端点。

因此 a 对我有意义并呈现最RESTful方法。

由于上述原因，

b 没有意义。请记住，在这类问题中，最困难的是引入第一个专用端点。当它完成后，下一个只是时间问题。

有时 c 对我来说很有意义，但我仍然试着解释;）

请记住，在设计/实施API时，您必须与规则保持一致 - 即使您自己设置规则。

返回资源上的聚合数据

1 个答案: