我使用Java 11和Spring Boot 2。我有一个简单的CRUD微服务，它在一个资源上运行，例如"；人"；，其具有大约10个场。我有以下4个端点：
方法GET：/v1/人/｛id｝
方法POST：/v1/人
方法PATCH：/v1/人/｛id｝/电子邮件
方法删除：/v1/人/｛id｝
从业务角度来看，PATCH端点只能用于更新一个字段("电子邮件")的操作，该字段的值在请求正文中传递。
所以，问题是：
- 可以吗，在PATCH方法的URI中我有/email，或者我必须有：/v1/person/{id}。这样做是不是不好，因为有什么理由不这样做
从我的角度来看，它看起来并没有那么糟糕，因为我们想要哪个属性(字段)，并且我们可以立即更新，但我怀疑这是否违反了命名端点的rest方法。
提前谢谢！
从REST的角度来看，PATCH和PUT都应该使用与用于获取资源表示的GET相同的目标资源。
这就是统一的接口约束：所有资源都以相同的方式理解消息，因此任何可以与其中一个资源进行通信的客户端都可以与所有其他资源进行通信。
但是。。。
在如何定义资源方面，您有很大的自由度。资源模型到数据模型的映射不必是一对一。获取一个图或相关信息并将其传播到几个不同的资源是正常的。(当然，你必须了解你正在进行的权衡。)
因此，如果你想通过一个资源获得用户配置文件，并通过另一个地址获得联系人地址，那没关系。或者你可以把它们组合起来。或者你可以有三种资源——一种是孤立的，第三种是组合的。一切都很好(再次进行权衡)。
您遇到的这种权衡的一个例子是：就通用组件而言，/v1/person/1和/v1/person/1/email之间没有隐含的关系，同样，/v1/person/1和/questions/66443217/patch-endpoint-name-rest-api之间也没有隐含的联系。
因此，当您建议更改/v1/person/1/email时，通用组件不会知道这意味着更改/v1/person/1。类似地，通用组件不会假设DELETE /v1/person/1对/v1/person/1/email有任何影响。
这太棒了！当资源真的不相关时。但是，当这两个资源相关时，可能会给您带来一些缓存失效问题。
这就是为什么我们必须坐下来设计我们的资源模型，这样当"；通过网络传输文件"；域向我们发送请求并解释我们的响应。
我不太确定我是否正确理解你所说的："通用组件"。
理解HTTP元数据的东西，而不一定理解特定资源的语义。示例包括
- 浏览器
- 远程web创作工具
- 缓存
- 蜘蛛/爬行器
- 代理人
所有这些都是理解HTTP应用程序的东西，而不一定了解我们在网络上传输的文档，或者它们的含义。
我不明白为什么当我们提议更改/v1/person/1/电子邮件时，通用组件不会知道这意味着更改为/v1/person/1
因为HTTP不是这样工作的。标识符只是标识符；拼写重叠并不意味着什么。
这很好，因为我们可以选择标识符拼写，让人类更容易阅读它们。但人类会看到机器看不到的标识符之间的关系。
如果你想描述资源之间的关系，以便机器能够理解它们，那么正确的机制是Web链接；如果你想宣布对该资源的更改也会使该资源失效，那么你需要类似链接缓存失效。。。遗憾的是，LCI似乎没有存活足够长的时间来进行标准化、注册和采用。
除了适当地利用HTTP谓词，资源命名可以说是最具争议性和最重要的概念创建一个易于理解、易于利用的Web服务API。什么时候资源命名良好，API直观且易于使用。完成糟糕的是，同样的API可能会让人觉得笨拙，难以使用懂以下是在创建新API的资源URI。
本文档基于restful，但解释了资源命名restful资源命名的最佳实践