Question

我正在使用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实现还是我完全不在思考？非常感谢思想/指导。

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

Answer 1

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

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

为了成功“做REST”，我们必须有所不同，并放弃所有关于RPC和CRUD操作的想法;一旦你拥抱RESTful，这些都是非常有限的！

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

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

根据您的联系人和事件关系的具体示例，了解您的'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原则。

Answer 2

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

一个是将动作映射到动词，如果动作非常少，那么就不会发生碰撞。因此，如果行动不是安全的，也不是幂等的POST，否则如果不安全但是幂等，那么PUT：

POST http://myhost/myservice/XYZ

其他是将操作定义为逻辑资源：

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

后来更富有，我赞成。

Answer 3

几点重要

RPC端点 - ＆gt; REST入口点
RPC读取方法 - ＆gt; REST GET on Resource
RPC创建方法 - ＆gt; REST POST操作
PRC删除方法 - ＆gt; REST DELETE操作
RPC SOAP消息 - ＆gt; REST PayLoad

additonaly，考虑一下缓存标题，内容类型标题，如@Consumes，@ Produces

将RPC样式的Web服务操作转换为REST服务

3 个答案: