RPC 风格的示例如何以资源为中心的风格建模答案

【问题标题】：How an RPC-style example would look modelled in a resource-centric styleRPC 风格的示例如何以资源为中心的风格建模
【发布时间】：2013-06-22 01:24:35
【问题描述】：

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

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

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

我的（简化的）示例是：

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

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

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

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

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

我的猜测是：

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

链接可能是什么（忽略指向自身的链接）？

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

【问题讨论】：

【解决方案1】：

你可能读过这两本好书：

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

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

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

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

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

模拟“获得工作”：

模特、求职：

模型将作业分配给用户：

使用 PUT 和 POST 有一些区别，你可以搜索一下。

希望对您有所帮助。

【讨论】：