我正在设计一个RESTful API，我的问题如下：在RESTful API中使用POST和PATCH管理关系的最佳实践是什么？当对方实体/实体已经存在/存在时，我应该何时何地允许API的消费者在实体之间建立关系？我的目标是（a）最小化代码和代码维护，（b）理解API的平衡比例和建立关系的API调用数量。最有限的标准是我自己开发和维护API。
如果有兴趣，我使用ASP.NET Core并将API（使用外部模型）和基于实体框架的数据层（使用数据模型）分成两个不同的层，其中API层引用数据层（API - ＆gt;数据）。
我想讨论http请求方法POST和PATCH的所有可能组合以及一对一，一对多和多对多的三种关系类型。
POST一对一
我在考虑允许API的使用者只允许新实体的POST请求通过，而对方实体与已发布实体类型的任何其他实体之间存在 no 关系。 / p>
另一个选择是永远不允许通过POST设置关系，但只允许通过PATCH更新。我赞成这个选项，因为它可以在分别处理关系时使实体更容易和更安全。更好的是，它只需要两个API调用 - 一个用于POST新实体，另一个用于PATCH甚至多个关系到许多不同的一对一相对实体。
POST一对多
一个选项是允许API的消费者只允许新实体的POST通过当对方实体的所有与已发布实体类型的任何其他实体没有关系时。较少的保存是允许消费者覆盖对方实体与已发布实体类型的另一个实体的现有关系。
另一种选择是不允许将单个实体的任何关系发布到许多实体，因为关系实际上是在相反的实体中设置的。我更喜欢只允许通过PATCH在相反的实体中设置关系，因为这是有效建立多对一关系的地方，并且它将实体的创建与建立关系分开。
发布多对多
我永远不会允许在多对多关系中为POST请求设置关系，但只允许PATCH在新实体和对方实体上建立新关系。由于这种关系的复杂性，我认为最好尽可能简化实体创建，并通过PATCH请求分别管理关系。
PATCH一对一
我不会设置任何限制，并允许API的使用者双方自由设置关系。
PATCH一对多
这对我来说是一个真正的困境 - API调用的数量与理解关系和代码行的容易程度。
一方面，我可以从单一实体的角度允许PATCH（它包含例如相反实体ID的数组）。这将只需要一次API调用来更新多个相对实体的关系，但这需要更多代码，因为数据层需要查找并遍历所有相反的实体。此外，从单一实体的角度更新有时很难理解 - 很多时候我更容易在引用同一个实体的所有相反实体中建立关系。
另一方面，我可以允许API的使用者单独更新所有相反的实体。这需要许多API调用，但我有时认为从这个角度更新更容易理解，并且无论如何都要在多个相反的实体中有效地设置关系。
我还不知道该怎么做。我正在考虑提供两种选择。
PATCH多对多
我能看到的唯一方法是允许API的消费者允许双方建立关系，因为这种关系的性质。
在详细阐述我的想法时，我认为最好的指导方针是将实体的创建与建立关系完全分开，并仅在有效建立关系的地方设置关系（模仿SQL表行为）。我假设后者是大多数API消费者应该熟悉的，第一个是保存API并且简单（以效率为代价）。
如果我错过任何案例，决策标准或没有考虑任何实施策略，请告诉我。
祝你好运， philippfx