如何以 RESTful 方式对 CANCEL 操作建模? [英] How to model a CANCEL action in a RESTful way?

问题描述

我们目前正在从我们的单体应用中处理较小的服务.我们的域与票务系统非常相似.我们已决定从域的取消流程开始.

We are currently in the process of wrangling smaller services from our monoliths. Our domain is very similar to a ticketing system. We have decided to start with the cancellation process of the domain.

我们的取消服务有一个简单的端点取消"，它接收票证的 ID.在内部，我们检索 id，对其执行一些与取消相关的操作并更新 store 中实体的状态.从商店的角度来看，取消门票和现场门票之间的唯一区别是一些属性.

Our cancel service has as simple endpoint "Cancel" which takes in the id of the ticket. Internally, we retrieve the id, perform some operations related to cancel on it and update the state of the entity in the store. From the store's perspective the only difference between a cancelled ticket and a live ticket are a few properties.

据我所知，PATCH 似乎是在这种情况下使用的正确动词，因为我只更新资源中的一个简单属性.

From what I have read, PATCH seems to be the correct verb to be used in this case, as am updating only a simple property in the resource.

PATCH /api/tickets/{id}
Payload {isCancelled: true}

但是 isCancelled 不是实体中的实际属性.在有效载荷中发送不属于实体的属性是否公平，或者我应该考虑对此请求进行建模的其他形式吗?我不想将整个实体作为有效载荷的一部分发送，因为它很大.

But isCancelled is not an actual property in the entity. Is it fair to send properties in the payload that are not part of the entity or should I think of some other form of modeling this request? I would not want to send the entire entity as part of the payload, since it is large.

我曾考虑创建一个新资源 CancelledTickets，但在我们的域中，我们永远不需要对取消的票进行 GET.因此不必创建新资源.

I have considered creating a new resource CancelledTickets, but in our domain we would never have the need to a GET on cancelled tickets. Hence stayed away from having to create a new resource.

推荐答案

公开资源的 GET 接口不是强制性的.

Exposing the GET interface of a resource is not compulsory.

例如使用

PUT /api/tickets/{id}/actions/cancel

提交取消请求.我选择 PUT 因为不会有超过一个有效的取消请求.

to submit the cancellation request. I choose PUT since there would be no more than one cancellation request in effect.

希望对您有所帮助.

这篇关于如何以 RESTful 方式对 CANCEL 操作建模?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！