Question

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

我将引用一个典型的例子。

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

npm

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

如果我想立即更新实体并从列表中删除绿色怎么办？或者可以在列表中添加新颜色？

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

类似于

的东西

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

谢谢，

UTSAV

Answer 1

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

烨;好消息是，当实体处于第一范式时，它们是相同的标准：

REST并不关心如何拼写URI

REST的很大一部分原因是客户端与数据存储的细节隔离开来。

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

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

然后，对于由NoSQL商店支持的API，这些拼写也应该令人满意。

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

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

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