设计RDF /链接数据API-我应该按数据图或按服务公开数据吗？

如何解决设计RDF /链接数据API-我应该按数据图或按服务公开数据吗？

我正在构建一个API，以将RDF数据连接到React前端。

数据存储在多个数据图中。 API有权访问所有数据图。 React将调用API来获取数据，然后将其显示给用户。大多数UI视图将需要来自多个不同图形的数据。

例如：

Datastore1_Variable1 + Datastore2_Variable3 -> UserView1 
Datastore1_Variable2 + Datastore3_Variable1 -> UserView2 

我的目的是构建一个面向服务的API，用户可以调用API / UserView1来获取在一次调用中构建UserView1所需的所有数据。

但是，建议我为每个数据存储区构建一个单独的API，并让React依次调用每个数据存储区API。在我看来，这将需要更多的往返调用并在前端进行复杂的联接。唯一的原因似乎是：“这就是我们一直这样做的方式。”

是否存在功能/效率方面的原因，为什么要分开显示数据图？

解决方法

我的目的是构建一个面向服务的API，用户可以调用API / UserView1来获取在一次调用中构建UserView1所需的所有数据。

这通常被认为是设计API的一种坏方法，并且在哲学上与围绕RDF和链接数据的原理相反。我知道这似乎违反直觉，因为替代方法是进行多个API调用以充分充实您的视图。要使用诸如API/UserView1之类的端点来构建API，意味着您已经设计了 only 可以与您的应用一起使用的API。两者紧密结合。除了一个非常特定的用例之外，您的API毫无用处。假设您提到这是一个 RDF API，那就告诉我该API需要遵循标准，并旨在实现最大的互操作性。

REST API通常对资源和集合进行建模。资源和集合的名称是“稳定的”（表示获取特定资源的URI）不变。如果您构建了level-3 REST api，则生成的有效负载将包含指向客户端可能感兴趣的其他资源和集合的链接。

正确组织API是一项值得努力的工作，尤其是如果该API具有较长的使用寿命的话。正确设计REST API并不是教条，设计决策经过深思熟虑，并具有目前尚不明显的实际实际意义。

由于您提到它是提供RDF数据的API，所以我的建议是使用JSON-LD进行响应。这遵循Web开发人员熟悉的许多约定，但包括RDF的好处。

如果是我，我还将考虑公开一个SPARQL端点。由于您的数据以RDF格式提供，因此SPARQL将允许客户从与特定应用程序的当前版本没有紧密联系的标准API端点中请求非常具体的图形。