RESTful 非规范化 (NoSQL) 实体的 API？

Question

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

我举一个典型的例子。

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

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

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

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

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

类似于

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

谢谢，

乌察夫

Answer 1

I was wondering whether we have any standards for writing RESTful APIs for entities that are not even in 1st Normal Form ??

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

REST 不关心 URI 的拼写方式

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

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

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

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

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

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

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

RESTful 非规范化 (NoSQL) 实体的 API？

RESTful APIs for unnormalized (NoSQL) entities?

rest

cassandra

nosql

microservices