羽毛定制服务方式——违反规则
Feathers custom service methods -- against the rules
Feathers 框架旨在坚持 REST 设计，我知道，但我认为我有一个边缘案例值得稍微打破规则。我想制作一个允许通过 HTTP 和 Socket.io.
以编程方式访问播放器控件的音乐播放器 API
然而，播放器并不是 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 实现这样的服务，而无需在 express 中全部手动完成？如果不可能，将自定义快递代码与应用程序的其余部分完美集成的最友好方式是什么？
虽然 Spotify 似乎是这样做的，但根据 HTTP specification 的说法，GET 是一种安全的方法，除了检索数据外不应该有任何副作用：
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".
Feathers 在这方面的限制是有意避免常见的陷阱（最坏的情况是，Google 爬虫进入并通过页面上的链接删除了一堆数据）。
使用 PATCH（或 POST 如果需要）时，您仍然有多个选项。根据用户 id 创建一个 player 服务并更新它的状态：
PATCH /player/<userId> { "state": "playing" }
创建一个单独的 actions 服务来接收玩家的状态变化：
POST /action { "userId": "<userId>", "state": "paused" }
优点是 Feathers 会自动通过 HTTP 和 websockets 公开这两个 API 并且您会自动获得两者的实时更新和身份验证，所有这些您都必须在普通 Express 中手动完成.
Feathers 框架旨在坚持 REST 设计，我知道，但我认为我有一个边缘案例值得稍微打破规则。我想制作一个允许通过 HTTP 和 Socket.io.
以编程方式访问播放器控件的音乐播放器 API然而，播放器并不是 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 实现这样的服务，而无需在 express 中全部手动完成？如果不可能，将自定义快递代码与应用程序的其余部分完美集成的最友好方式是什么？
虽然 Spotify 似乎是这样做的，但根据 HTTP specification 的说法，GET 是一种安全的方法，除了检索数据外不应该有任何副作用：
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".
Feathers 在这方面的限制是有意避免常见的陷阱（最坏的情况是，Google 爬虫进入并通过页面上的链接删除了一堆数据）。
使用 PATCH（或 POST 如果需要）时，您仍然有多个选项。根据用户 id 创建一个 player 服务并更新它的状态：
PATCH /player/<userId> { "state": "playing" }
创建一个单独的 actions 服务来接收玩家的状态变化：
POST /action { "userId": "<userId>", "state": "paused" }
优点是 Feathers 会自动通过 HTTP 和 websockets 公开这两个 API 并且您会自动获得两者的实时更新和身份验证，所有这些您都必须在普通 Express 中手动完成.