这个通用 REST 服务是个好主意吗？答案

【问题标题】：Is this generic REST service a good idea?这个通用 REST 服务是个好主意吗？
【发布时间】：2016-02-24 14:57:06
【问题描述】：

我有一个关于特定 REST 服务设计是否好的问题。

背景是拥有一个内部单体系统（将称之为“主系统”）处理例如顾客。然后是外部组件，其中包含有关人员的附加信息，这些信息可能与主系统中的客户 1-1 对应，也可能不对应。

目前，对于这些外部组件中的个人/客户有或可能与何种数据相关联，尚无明确规范。我提出的建议设计是一个 REST 服务，它公开一个 API 供外部系统调用，以便为组件提供与人员相关的任意数据。这样做的想法是，通过这样做，主系统将有一个地方可以去，以获取客户/人员的外部数据。此 REST 服务的一个提议要求是，当外部组件将新类型的数据加载到其中时，该数据会自动被服务访问，而无需以任何方式更改或重新部署。而“新数据”一般是指一种新型的键值集。例如。最初，该服务可能会为由 customerId 标识的客户提供数据。然后一个外部组件决定发布一些与 SSN 相关的数据。这应该自动要求服务可以通过在请求中提供 SSN 来查询此数据。

为了避免更改/重新部署服务的需要，我假设解决方案必须有一个非常通用的参考方案，例如 http://url/generic-resource-name/?id=[customerId]&keyType=cusomterId 要求中实际上并没有限制与个人关联的数据，只是它的键由一个值组成。

示例用例序列可以是：

所以对于这个问题：实施这样的通用服务是个好主意吗？它如何与 REST 的原则押韵：服务将在其上运行的名词必须非常通用，实际上几乎没有“资源”或“数据”，这对我来说本身就是一种气味。

【问题讨论】：

在我看来，您已经迈出了一步过于笼统。如果您的 REST 服务实际上将成为键/值存储，那么也许您可以使用现成的键/值存储。
好的，谢谢。对这种现成键值存储的候选人有什么建议吗？最好是它带有一个易于设置的 REST api，或多或少满足我描述的需求？

标签： rest architecture components

【解决方案1】：

那么问题来了：实现这样一个通用的方法是个好主意吗？目的服务？

我相信不会。您将直接进入Inner platform effect antipattern。你必须非常小心，否则你可能会像Vision一样结束。

还请阅读 Fowler 的 PoEAA book 中的“分布式对象的魅力”一章。只是要小心。

【讨论】：

感谢您阅读有关 Vision 的有趣和有趣的文章。我有点同意，但不完全同意，因为 REST 服务不会是内部的东西。而是独立于平台的东西。
@tyronecopex 当然，你知道得更好，因为这是你的系统，我可能会错过一些东西。另请阅读 Fowler 的 PoEAA book 中的“分布式对象的魅力”一章。只是要小心。