羽毛定制服务方法——违反规则



我知道,Feathers框架旨在坚持REST设计,但我认为我有一个值得打破规则的边缘情况。我想制作一个音乐播放器 API,允许通过 HTTP 和 Socket.io 以编程方式访问播放器控件。

然而,玩家并不是一个简单的getputpatchpostdelete的情况。将为每个用户创建一个播放器,并且永远不会被删除,只会更改。我想要自定义方法,如播放、暂停、setQueue 等方法的子路由,例如PATCH /player/playPATCH /player/pause.

这正是 Spotify 在他们的 API 中做到这一点的方式,这比每次向同一端点发送PATCH请求并手动更新玩家数据更有意义,即。PATCH /player {nowPlaying: {index: newIndex}}跳到下一个轨道,API 的用户必须知道玩家数据的架构及其操作方式。相反,像PATCH /player/next这样的东西更有意义,也更易于使用。

如何使用 Feathers 的 API 实现这样的服务,而无需在 express 中手动完成所有操作?如果不可能,那么将自定义快速代码与应用程序的其余部分很好地集成的最友好方法是什么?

尽管Spotify似乎是这样做的,但它并不是根据HTTP规范声明GET是一种安全的方法,除了检索数据之外不应该有任何副作用:

特别是,已经确立了 GET 和 HEAD 方法不应具有执行检索以外的操作的重要性。这些方法应该被认为是"安全的"。

Feathers在这方面的局限性非常有意地避免常见的陷阱(最坏的情况是,Google爬虫通过页面上的链接进入并删除一堆数据)。

使用PATCH 时,您仍然有几个选项(如果需要,也可以使用 POST)。根据用户 ID 创建player服务并更新其状态:

PATCH /player/<userId> { "state": "playing" }

创建单独的actions服务,用于接收玩家的状态更改:

POST /action { "userId": "<userId>", "state": "paused" }

优点是Feathers将通过HTTP和websockets自动公开这两个API,并且您可以自动获得两者的实时更新和身份验证,所有这些都必须在普通Express中手动完成。

相关内容

  • 没有找到相关文章

最新更新