rest - RPC 样式的示例如何以资源为中心的样式建模

Question

几天来，我一直在网上阅读有关 REST 的信息，并且正在为 HATEOAS 的概念而苦苦挣扎。

我认为我正在苦苦挣扎，因为我没有正确理解如何将数据建模为资源和（状态转换？）资源之间的链接。我相信我的问题是我所有的经验都是 OO 和 RPC，我不习惯以资源为中心的方式思考。

获得理解的唯一方法是从我的世界中举一个例子，说出我认为可能看起来像以资源/链接为中心的方式建模的内容，然后将其扔到那里被烧毁。刻录完成后，我至少应该对我不理解的东西有更好的理解。

我的（简化）示例是：

我是一名承包商，例如管道工。我有许多工作分配给我。我可以搜索我的工作，指定简单的参数，例如目标日期范围。我可以开始分配给我的任何工作。当我开始工作时，我可以选择指定开始工作的时间，或者如果我现在开始工作，则将其留空。

如果我以 RPC 方式实现它，我可能会向调用者公开两种方法：

ListOfJobs GetJobs(search parameters)
StartJobResult StartJob(jobID, optional start datetime)

如您所见，我正在考虑对象和操作。

如果我在考虑资源和链接，资源可能是什么？

我的猜测是：

假设以上任何一项都是正确的（我怀疑它是正确的），“searchidentifier”和“attendanceidentifier”应该是什么？前者在我的 RPC 世界中没有身份；它只是参数。后者将由 DateTime 标识。

链接可能是什么（忽略自我链接）？

如果这是一个重复的问题，请接受我的道歉并将其关闭。（我找不到重复，但我可能一直在使用不正确的术语进行搜索。）

score 0 · Accepted Answer

你可能读过这两本好书：

回到你的问题。更实际的思考或应用 REST 作为起点（至少它对我有用）的方式是按照以下方式思考：

1) 仅使用 HTTP 'GET/POST/PUT/DELETE' 作为对域 'actions' 建模的方式。就像您处理数据库时一样，您的所有操作都映射到CURD。

2) URI/URL 仅用于标识资源。您的 URI 中不应有任何“操作”。

3) 交换的数据应该在 HTTP 消息的正文中。只是为了简化讨论，而不是讨论如何对数据本身进行建模

这就是我想到的。我确信有更好的方法来建模你所拥有的东西，但它应该遵循相同的原则☺ 例如，URL 模式的外观完全取决于你的应用程序域以及客户端和后端之间的意义。

为“获得工作”建模：

建模，求职：

要将作业模型分配给用户：

使用 PUT 与 POST 存在一些差异，您可以四处搜索。

希望这有帮助。

1 回答 1