API端点设计：技术规格或产品

Question

我们有2位开发人员在设计RESTful API端点方面存在冲突。基本上，假设我们手头有Facebook产品，有一个表格用于帖子。

第一位开发者发表意见

• 我们应该按产品分开端点，而不是技术存储。为此，我们将为用户facebook帖子和其他facebook帖子提供端点。

/v1/wall/mypost

/v1/wall/other

• 就这样，我们可以配置每个可能返回差异结果的产品

第二位开发者不同意，提出意见

• 如果是这样的话，它会产生无限的终点。它将有/wall/someone，/wall/sometwo。

• 我们应该有单个端点，让它成为查询的一部分。恩。 /wall?user=someone，/wall?user=sometwo

• 端点应该看起来像技术架构，它返回相同的结果，为什么它必须分离，以便在维护代码时增加更多的工作。

设计端点的好习惯是什么？它应该是产品的终点吗？或者是应该通过架构？

Answer 1

它应该取决于什么＆＃39;资源＆＃39;该服务假设从API用户角度进行管理，而不是从内部实现进行管理。

有了这个，如果服务要管理说，一个可以由某人识别出来的资源，有些人可以识别这些资源。然后，正确的建模方法是

/壁/有人/

/壁/的部分成为/

在这种情况下，＆＃39;某人＆＃39;和“有些＆＃39;是两种不同的资源，你可以拥有无​​限的资源;但这与内部存储或实施无关。

在后端，应该有一些网址模式来提取某人＆＃39;和“有些＆＃39;作为资源并将它们映射到内部实现细节。

Answer 2

你说的这些“终点”是什么？这是SOAP术语！ RESTful Web服务是根据URL唯一标识的“资源”定义的。

资源通常代表域模型中的实体（例如，用户）。实体的ID通常用作URL中的路径元素（大多数REST库的术语中的“路径参数”，例如JAX-RS）。查询参数只应用于对服务器端的结果进行排序/过滤。

您的第一位开发人员更接近正确。