使用自定义服务方法 - 违反规则

时间:2017-11-25 18:01:35

标签: rest audio-player feathersjs feathers-service

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

然而,播放器不是getputpatchpostdelete的简单案例。将为每个用户创建一个播放器,永远不会删除,只会更改。我想在方法的子路由上使用自定义方法,如play,pause,setQueue等,例如PATCH /player/playPATCH /player/pause

这正是how Spotify does it in their API,它比每次向同一端点发送PATCH请求并手动更新播放器数据更有意义,即。 PATCH /player {nowPlaying: {index: newIndex}}跳到下一首曲目,API的用户必须知道播放器数据的架构及其运作方式。相反,像PATCH /player/next这样的东西更有意义,更容易使用。

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

1 个答案:

答案 0 :(得分:1)

虽然Spotify似乎是这样做的,但是根据HTTP specification的说法,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中手动完成。