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

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 实现，还是我完全偏离了我的想法？非常感谢想法/指导。

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

Answer 1

Question is whether it makes sense for the RPC methods to map to REST resources as indicated in the post

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

为了成功地“做REST”，我们必须有一点不同的思考方式，并放弃所有RPC和CRUD操作的想法；一旦您拥抱 RESTful，这些确实相当有限!

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

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

以联系人和事件关系的具体示例为例，重要的是要了解“AssignContactToEvent”是在 Web-API 层下发生的操作，无法以 REST 方式建模；我希望这一点在以下示例中会变得清晰:)

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

/contacts

/events

这些资源对由 ID token 标识的单个联系人或事件进行建模:

/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 原则。