用于非规范化（NoSQL）实体的 RESTful API？答案

【问题标题】：RESTful APIs for unnormalized (NoSQL) entities?用于非规范化（NoSQL）实体的 RESTful API？
【发布时间】：2017-07-30 16:24:11
【问题描述】：

我目前正在从事一个项目，我们正在使用 Cassandra 作为我们的数据库在 Scala 中开发一组微服务。我想知道我们是否有任何标准为甚至不在第一范式中的实体编写 RESTful API ??

我会举一个典型的例子。

考虑一个实体集 Fruits。在传统的 RDBMS 中，如果我们要存储水果的颜色，我们可以创建一个表 Colors has 与每种颜色关联的整数作为其主键。为了将颜色映射到水果，您可以有另一个将水果映射到颜色的关系。我们的数据库设计满足 Boyce Codd 范式，我们可以设计直观的 REST 端点。

/fruits(/:id)
/colors(/:id)
/fruits/:id/colors
/colors/:id/fruits

输入 NoSQL 数据库。颜色是 Fruits 实体集本身的一个属性，它的域是一组 varchar。如果我要将 Apple 插入数据集并关联颜色为红色和绿色，我必须将这些字符串作为该记录的一部分存储在一个集合中。

如果我现在想更新实体并从列表中删除绿色怎么办？或者也许在列表中添加一种新颜色？

无论底层数据库设计如何，都应该将其分解为一个单独的端点吗？还是应该是有效载荷的一部分？

类似的东西

{
    "name": "Apple",
    "colors": ["green', "red"]
}

谢谢，

乌萨夫

【问题讨论】：

标签： rest cassandra microservices nosql

【解决方案1】：

我想知道我们是否有任何标准可以为甚至不在第一范式中的实体编写 RESTful API？？

是的；好消息是它们与实体处于第一范式时适用的标准相同：

REST 不关心 URI 的拼写方式

REST 的很大一部分意义在于客户端与您的数据存储细节隔离。

换句话说，当您将数据存储在 RDBMS 中时，如果您认为这些拼写有助于识别集成域中的资源

/fruits(/:id)
/colors(/:id)
/fruits/:id/colors
/colors/:id/fruits

那么这些拼写对于由 NoSQL 存储支持的 API 来说也应该是令人满意的。

您的实现的工作是弥合集成域中资源的语义含义与您的存储之间的差距。

这是同一想法的另一种拼写；从客户端的角度来看，所有 HTTP 服务器都是文档存储。 URI 是键，表示是值。有无限数量的可用键，以及预计任何给定键都支持的少量动词（方法）。

让您的服务（无论它是什么）看起来像一个愚蠢的 HTTP 文档存储，这是您的 API 的工作。

【讨论】：