如何在我们的API和

Question

我们销售一种车队管理解决方案:它包括一个移动应用程序、一个web应用程序和一组API。

技术上，API和web应用程序是用C# .net (asp.net、mvc和asp.net webapi)开发的。我们使用的是源代码管理。

我们的标准解决方案是为一定数量的客户实现的。我们现在面临的问题是，我们最近有几个大客户希望为自己的情况定制产品。例如:在用户帐户管理模块中，我们的一个大客户请求链接3个附加数据(员工的内部标识号、仓库代码和联系号)：在我们的标准API中，这个数据没有任何关系。

因此，问题是如何修改我们的基本代码，并将我们的API开发为一个产品，同时满足我们客户的需求。我们确实希望避免重复的代码，这是过于具体和难以维护，同时试图有一个稳定的公共基础。

我们中的一些人说，我们必须为这个客户计划创建一个新的git存储库，然后推动我们的产品分支，最后进行客户所要求的特定更改。另一些人希望修改每个规范的产品基代码(如果需要的话)，以便设置一个扩展点，以便让客户能够扩展它(例如，在api和用户帐户的底层数据库表中添加3个新的具体字段)

Answer 1

在这个场景中没有灵丹妙药，但是您必须为您必须及时面对的每个定制方面评估一个解决方案，试图将核心api与自定义服务分离开来。

如果客户只需要扩展与某些资源(公司、用户、资产)相关的信息，最灵活的解决方案是将属性作为客户直接提供的密钥/值对引入。属性可能具有客户定义的模式，但这会使用户/开发人员的体验更加复杂，因为它必须提前声明键和类型。

示例：

PUT /users/:userId/props/mykey
{
  type: "string",
  value: "foo"
}

PATCH /users/:userId/props/mykey
{
  value: "bar" (if it was a number, i'd have a 400 error)
}

GET /users/:userId/props
{
  mykey: { 
    value:"bar",
    type: "string"
  },
  mynumber: {
    value: 3,
    type: number
  }
}

当自定义对域模型产生影响时，开发一个充当核心api代理的专用后端是合理的，会有一个端点，如api.mycompany.com/rich-customer/v1.如果您正在通过移动/web应用程序提供访问，则可以使用后端换前端。

最后，如果定制对平台演化的影响很小，或者看起来对其他客户来说是合理和有用的，那么为什么不把它们当作核心apis的新特性呢？

Answer 2

我认为这是很好的，你看到的需求，因为将有一个庞大的，有利可图的客户群，谁将购买你的产品，如果它可以合理地集成到几十个，如果不是数百个系统，他们已经运行。不过，不要对此进行黑客攻击，考虑一下用您的数据存储用户数据的可持续方法。

一个简单的解决方案是在业务对象中有一个用户数据字段。通常，这将是一个文本字段，内容对您自己的应用程序不感兴趣。你唯一的工作就是接受它写的内容，在读的时候显示它。

大多数客户应该能够使用一个用户数据字段。例如，他们可以将用户ID存储在字段中，然后在自己的系统中查找其余的信息。重点是，不要从表面上看待他们的需求，看看能满足他们目标的最低限度的实现是什么。

如果客户需要多个值，他们可以将这些值填充到JSON对象中，然后存储JSON (XML，AVRO .)对象在“用户数据”字段中。

企业级产品通常有一个可扩展的模式，客户实际上可以添加自己的类型化数据。

我建议不要使用特定于客户的字段或(gasp)分支。