羽毛定制服务方法 - 违反规则
羽毛框架被设计为坚持REST设计，我知道，但我认为我有一个值得打破规则的边缘案例。我想制作一个音乐播放器API，允许通过HTTP和Socket.io编程访问播放器控件。羽毛定制服务方法 - 违反规则
球员，但是，并不是get，put，patch，post和delete一个简单的例子。一名球员将为每个用户创建，并且永远不会被删除，只会被更改。我想在方法的子路径上使用自定义方法，例如播放，暂停，setQueue等，例如PATCH /player/play和PATCH /player/pause。
这正好是how Spotify does it in their API，它比每次向同一端点发送PATCH请求和手动更新播放器数据更有意义。 PATCH /player {nowPlaying: {index: newIndex}}跳到下一个轨道，其中API的用户必须知道玩家数据的模式以及它如何操作。相反，像PATCH /player/next这样的东西更有意义并且更易于使用。
如何使用Feathers的API实现像这样的服务，而不是手动全部手动执行？如果这是不可能的，那么将自定义快速代码与其他应用程序很好地整合在一起的最友好的方式是什么？
尽管Spotify的似乎是这样做的，它没有按照该规定，得到的是不应该比检索数据之外的任何副作用的安全方法HTTP specification：
特别是，该惯例已经确立了GET和HEAD方法不应该具有除了检索之外采取其他行为的意义。这些方法应该被认为是“安全的”。
Feathers在这方面的局限性非常有意避免常见的陷阱（最糟糕的情况是，Google抓取工具通过访问页面上的链接删除了大量数据）。
使用PATCH（或者如果需要，您仍然可以使用POST）时仍然有几个选项。创建基于用户ID的player服务和更新状态：
PATCH /player/<userId> { "state": "playing" }
创建一个单独的actions服务，收到了玩家状态的变化：
POST /action { "userId": "<userId>", "state": "paused" }
的优点是羽毛就会自动曝光两种这些API通过HTTP和websockets，并且您自动获得实时更新和身份验证，所有这些都必须通过简单的Express手动执行。