正确的URI的REST调用来创建两个实体
之间&删除关系
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是用于替换整个实体（资源）和修补程序是否正确？
不完全。 PUT意味着请求的消息主体是资源的替代表示。 PATCH表示请求的消息主体是补丁文档。
语义中没有任何内容阻止您使用PUT更改大文档中的单个元素，或者使用PATCH完全替换表示。
但客户端可能更喜欢PATCH到PUT，因为补丁文档比替换表示小得多。或者它可能更喜欢PUT到PATCH，因为消息传输是不可靠的，并且PUT的幂等语义使得重试更容易。
“unfollow”动作是否有其他副作用？ – inovaovao
截至目前，唯一的副作用是几个分片计数器的减量（B的跟随者计数，跟随A的计数）。 – markvgti