羽毛定製服務方法 - 違反規則

Question

羽毛框架被設計爲堅持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實現像這樣的服務，而不是手動全部手動執行？如果這是不可能的，那麼將自定義快速代碼與其他應用程序很好地整合在一起的最友好的方式是什麼？

Answer 1

儘管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手動執行。