4

我正在使用 ASP.NET Web API 将基于 SOAP 的 RPC 样式“Web 服务”转换为基于 JSON 的 REST Web 服务。AddXYZ / UpdateXYZ / RemoveXYZ 等方法干净地映射到 POST/PUT/DELETE 的 HTTP 动词。是否有任何最佳实践/指导将典型的 RPC 样式操作（例如“ExecuteXYZ”或“AssignXYZ”样式方法）映射到它的 REST 对应项？我的看法是，此类操作将映射到相应的 URL 可寻址资源，例如“ExecuteXYZRequest”和“AssignXYZRequest”

http://myhost/myservice/ExecuteXYZRequest
http://myhost/myservice/AssignXYZRequest

然后，执行“ExecuteXYZ”的请求将转换为 POST 操作。

获取提交的请求将转换为 GET（通常用于获取提交的请求的状态）。

http://myhost/myservice/ExecuteXYZRequest/1   <--- 1 is the ID of the request

取消请求（假设它是可取消的）将转换为 DELETE

POST 不会真正映射到任何东西。

以上听起来像是一个合理的 REST 实现，还是我完全不在乎我的想法？非常感谢思想/指导。

更新 这是我试图建模的具体示例：联系人和事件实体之间的多对多关系。将联系人的成员资格建模为 REST 资源的最佳方法是什么，以便可以从事件中添加/删除联系人。在 RPC 领域，这将是诸如“AssignContactToEvent”之类的方法，它获取两个实体的 ID 并建立这两者之间的关系。如何在 REST 中自然地将其建模为资源。我记得有一个链接和“rel”的概念，但找不到一个具体的实际示例来说明如何使用 Web API 对这样的东西进行建模

4

3 回答 3

7

问题是 RPC 方法映射到 REST 资源是否有意义，如帖子中所示

简而言之; 不，以您描述的方式将方法映射到资源是没有意义的:)

为了成功地“做 REST”，我们必须换个思路，摒弃 RPC 和 CRUD 操作的所有想法；一旦你接受了 RESTful，这些真的是相当有限的！

REST 中信息的关键抽象是资源。任何可以命名的信息都可以是资源：文档或图像、时间服务（例如“洛杉矶今天的天气”）、其他资源的集合、非虚拟对象（例如人）等等. 换句话说，任何可能成为作者超文本参考目标的概念都必须符合资源的定义。资源是到一组实体的概念映射，而不是在任何特定时间点对应于映射的实体。 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

方法或动作/动词不是资源，因此它在 URI 中没有位置——当然，除非您正在构建一个允许人们创建自己的方法的应用程序，这将是相当不寻常的！

以联系人和事件关系的具体示例为例，重要的是要了解您的“AssignContactToEvent”是在 Web-API 层下发生的操作，不能以 RESTful 方式建模；我希望这将在以下示例的过程中变得清楚:)

首先，我们需要一些好的资源来对所有联系人列表和所有事件列表进行建模：

/contacts

/events

这些资源对由 ID 令牌标识的单个联系人或事件建模：

/contacts/{contact_id}

/events/{event_id}

您的应用程序的用户想知道谁参与了特定事件，因此我们需要一个资源来模拟事件参与者的列表：

/events/{event_id}/participants

当我们想将联系人添加到事件时，我们可以将最小的联系人表示（仅包含联系人 ID）发布到事件的参与者列表：

POST /events/{event_id}/participants/ HTTP/1.1
Content-Type: application/json

{'id': {contact_id}}

要从事件中删除联系人：

DELETE /events/{event_id}/participants/{contact_id} HTTP/1.1

您的应用程序用户还希望一目了然地看到联系人参与的事件，因此您需要另一个资源来对此进行建模：

/contacts/{contact_id}/events

同样，您现在可以获取联系人的事件列表，并使用 POST 分配事件：

POST /contacts/{contact_id}/events/ HTTP/1.1
Content-Type: application/json

{'id': {event_id}}

重要的一点是，每当您需要对新事物进行建模时，您就创建了一个资源。如何存储数据对象的属性和关系的细节在 Web-API 后面被抽象出来。事实上，数据存储技术将来可能会发生变化，比如从关系存储到对象存储，或者您更改编程语言或框架，但在所有情况下，您的 URI（和 Web-API）都保持不变。REST 和 HTTP 旨在超越底层运行的技术。

作为创建新资源的最后一个示例，考虑一个对具有组织者角色的联系人列表建模的资源：

/events/{event_id}/organisers

或者这个模拟联系人正在组织的事件列表的模型：

/contacts/{contact_id}/events-organised

如果您有身份验证系统，那么您可能希望查看您正在参加的活动：

/my-account/events

我希望这有助于阐明 Web-API 的目的并遵循 ​​RESTful 原则。

于 2013-01-30T13:19:11.033 回答
2

到目前为止，我看到了两种方法。

一种是如果动作很少，则将动作映射到动词，这样就不会发生冲突。因此，如果动作不安全也不幂等POST，则如果不安全但幂等，则PUT：

POST http://myhost/myservice/XYZ

另一种是将动作定义为逻辑资源：

POST http://myhost/myservice/XYZ/Assignment

后来更富有，我赞成这一点。

于 2013-01-30T10:06:49.387 回答
1

几个重点

  • RPC 端点 -> REST 入口点

  • RPC 读取方法 -> 资源上的 REST GET

  • RPC 创建方法 -> REST POST 操作

  • PRC 删除方法 -> REST DELETE 操作

  • RPC SOAP 消息 -> REST PayLoad

additonaly，想想缓存头，像@Consumes，@Produces这样的Content-Type头

于 2013-01-30T05:05:36.187 回答