我需要通过REST调用创建和删除两个不同实体之间的关系。
假设用户A(当前用户)将跟随或不跟随用户B.跟随关系的存在由关注实体的存在或缺席表示(跟随(B,A)意味着A跟随B)。
电话应该是:
POST /api/follow/{user-b-id} // to follow
and
DELETE /api/follow/{user-b-id} // to un-follow
其中用户A的身份是从发送的令牌中推断出来的,以验证呼叫。
或者它们应该基于正在执行的行动:
POST /api/follow/{user-b-id} // to follow
and
POST /api/unfollow/{user-b-id} // to un-follow
我怀疑要使用哪些方法(POST,PUT,DELETE等)以及URI是否应该引用正在执行的操作(动词?)。由于我正在重新设计一个API,我想接近“正确”(是的,我确实认为这有点主观)REST API设计对我的项目有意义。
答案 0 :(得分:1)
正确的决定还取决于项目中其他资源的映射方式。相同的风格更好,但如果没有偏好,以下可能具有更容易实现和记忆的优势
POST /api/follow/{user-b-id} // to follow
and
POST /api/unfollow/{user-b-id} // to un-follow
答案 1 :(得分:1)
正确的REST调用URI以创建&删除两个实体之间的关系
REST并不关心您用于URI的拼写;就REST而言,/182b2559-5772-40fd-af84-297e3a4b4bcb
是一个完美的URI。拼写的限制不是来自REST,而是来自本地编码标准。
通用标准是考虑包含项的集合资源;这样,通过向收集资源发送消息来建模将项目资源添加到集合,并且通过向项目资源发送消息来建模移除项目资源。例如,Atom发布协议以这种方式工作 - POST to a collection resource添加新条目,DELETE to the item resource删除条目。
遵循这种方法,通常的指导方针是为集合命名集合资源,项目资源从属于它。
// Follow
POST /api/relationships
// Unfollow
DELETE /api/relationships/{id}
id
此处可能是user-b-id
,也可能是其他内容; REST中的一个核心思想是服务器是其URI空间的权限;服务器可以根据自己的判断将信息嵌入到URI中并且仅供其自己使用。消费者应将标识符视为不透明单位。
我怀疑使用哪些方法(POST,PUT,DELETE等)以及URI是否应该引用正在执行的操作(动词?)。
有时候请注意,即使使用的主要媒体类型(HTML)本身仅支持GET和POST,万维网仍然具有爆炸性的成功。
从技术上讲,你可以使用POST来处理所有事情。 HTTP uniform interface为您提供全权委托。
PUT
,DELETE
,PATCH
都可以被视为具有其他语义的POST
:unsafe方法的特化。 PUT建议使用幂等替换语义,DELETE建议删除PATCH以获取全部或全部更新。
引用该操作并非错误(REST不关心拼写,请记住),但它确实表明您正在考虑效果消息而不是消息正在作用的资源。
JSON Patch可能是一个值得注意的有用示例。 operations(添加,删除,替换等)被编码到补丁文档中,URI指定应该使用这些操作修改哪个资源。
Jim Webber以这种方式表达了这个想法 - HTTP是一个文档传输应用程序。有用的工作是交换文件的副作用。 URI标识用于导航集成协议的文档。
因此,如果您的URI需要一致的,人类可读的拼写,实现这一目标的一种方法是阐明该协议及其组成的文档。
如果要修改实体(资源)属性的子集,PUT是替换整个实体(资源)和PATCH是否正确?
不完全。 PUT表示请求的消息体是资源的替换表示。 PATCH表示请求的消息体是补丁文档。
语义中没有任何内容阻止您使用PUT来更改大型文档中的单个元素,或者使用PATCH来完全替换表示。
但客户端可能更喜欢PATCH到PUT,因为补丁文档比替换表示要小得多。或者它可能更喜欢PUT到PATCH,因为消息传输是不可靠的,并且PUT的幂等语义使得重试更容易。
答案 2 :(得分:1)
我想说,如果你传递了关系/链接的id /从a到b,请使用删除动词。这样,你的路线就是相当明确的。它接受某个对象的id并删除它。
但是,在您的示例中,您传入的是另一个用户的id,然后您必须执行一些逻辑来查找两者之间的关系/链接/跟随对象并将其删除。在我看来,这更像是一个帖子而不是删除,因为你需要做额外的工作。无论如何,似乎相当主观的是哪一个是"对",