使用RESTful API设计使用FK删除

我有一个名为

itemlink

的表，其中包含三列

id

，

parentId

，

childId

如果我想获取所有itemlinks，那么我将调用

get/itemlink

，如果我想获取属于特定父项的所有itemlinks，那么我将添加一个查询字符串

get/itemlink？parentId=5

，该参数是可选的

但是，如果我处理的是delete，并且我想让客户端能够删除属于某个特定父级的所有itemlinks，那么我不愿意使用一个url来删除所有itemlinks

DEL/itemlink

，这听起来不是最佳（或安全）实践，那么实现这一点的最佳方法是什么呢

---

当请求删除时，我可以考虑强制客户端添加parentId的一个选项是使用一个端点，如

/itemlink/parent/{id}

，但这是否违反了正确REST设计的规则？

资源和子资源都涉及到您的案例中。i、 亲子关系。在我看来，关系（itemlink）不应该在RESTAPI中作为资源公开，这实际上是您的案例中令人困惑的地方

我将用一个与您类似的示例用例来解释这一点

Customers - Parent table 
Orders - Child table
LinkId - CustomerId - OrderId - Link table

在这种情况下，API必须是

/customers/$customer_id/orders - (GET) - Get all orders of the customer
/customers/$customer_id/orders/$order_id - (GET) - Get a particular order of the customer
/customers/$customer_id/orders - (POST) - Create a new order for the customer
/customers/$customer_id/orders/$order_id - (PUT) - Edit a particular order of the customer
/customers/$customer_id/orders/$order_id - (DELETE) - Delete all the orders of the customer

---

至于删除FK关系，当客户关闭其帐户时，所有订单都应该被删除，这将通过

/customers/$customer\u id-HTTP DELETE

URI或API设计发生，实际上这不是REST的主题之一，因为响应应该只包含客户端可以用来执行任务的链接。这里重要的不是URI本身，而是关系名，用来告诉客户端URI的实际用途。如何构建这样的URI取决于您如何触发删除以及是否自动级联。因此，我投票决定结束这个问题，因为这个问题很可能只得到自以为是的答案。HTTP（或REST）定义子结构URL自动遵循父子关系。更准确地说：默认情况下，它们根本不相关。这两者之间的关系需要通过链接“建模”。此外，删除“父”资源不会自动推断子资源也因此被删除。HTTP规范声明，不能保证删除任何数据。该行为是特定于实现的，可能只删除这两个资源或一个或两个（多个）资源之间的链接。这意味着itemlink是有效的资源？？子资源不应被视为单个资源，对吗？

itemlink

可能是一个表，用于解决3NF表设置中的N:M关系。通常，将关系模型直接映射到资源上是一个坏主意，因为您可以将大量的数据聚合到资源中，并链接到其他资源。关于什么是资源和什么不是资源，也没有对错之分。这相当依赖于领域和问题，也可能由不同的实现者实现。此外，子资源是否可以或应该建模为自己的顶级资源也没有对错。您可以为您的URI结构应用一个

可以在没有其他资源的情况下存在的
模式。最后，REST并不真正关心，因为客户端从当前状态接收到它可能使用的任何URI，并且无论如何接收到下一个响应，客户端不应该进一步解释URI，而应该使用链接关系名称来确定调用URI的用途。链接关系名称的这些语义可以在媒体类型或进一步的协议（即
next
，
prev
，…）中进一步定义。在IMO中，如果必须指定父资源以标识子资源，则最好将其放在url中，而不是将其作为查询参数。但是，在我的示例中，客户ID可以是查询参数，而不是url结构，它可以充当作为主要资源的orders资源的过滤器。但在考虑组织的成员资源示例时，最好使用/organizations/id/members。我也非常同意您的观点，即模式纯粹依赖于开发人员和问题。