フェザーのカスタムサービスメソッド - ルールとの比較

Question

フェザーフレームワークはRESTデザインに固執するように設計されていますが、ルールを少し破る価値があると私は思っています。私はHTTPとSocket.ioを介してプレーヤーコントロールにプログラム的にアクセスできる音楽プレーヤーAPIを作りたいと思っています。

プレイヤーは、しかし、get、put、patch、post、およびdeleteの単純なケースではありません。 1人のプレイヤーがすべてのユーザーに対して作成され、削除されることはなく、変更されるだけです。メソッドのサブルートにplay、pause、setQueueなどのカスタムメソッドが必要です（たとえば、PATCH /player/playおよびPATCH /player/pause）。

これはまさにhow Spotify does it in their APIであり、それはすなわち、同じエンドポイントに毎回PATCH要求を送信し、手動でプレーヤーのデータを更新するよりもはるかに理にかなっています。 PATCH /player {nowPlaying: {index: newIndex}}を次のトラックにスキップします。ここで、APIのユーザーはプレーヤーデータのスキーマとその操作方法を知る必要があります。代わりに、PATCH /player/nextのようなものがはるかに理にかなって使いやすくなります。

私はどのようにこのようなサービスを実装するのですか？それが不可能な場合は、カスタムエクスプレスコードを他のアプリとうまく統合する最もフレンドリーな方法は何ですか？

Answer 1

楽しんでるが、そのように行うと思われるが、GETでデータを取得する以外の任意の副作用を持つべきではない安全な方法であると述べているHTTP specificationに応じていない。特に

、 GETとHEADのメソッドは検索以外のアクションをとるべきではないという慣習が確立されています。これらの方法は「安全」と考えられるべきです。

その点で羽の限界は（最悪の場合は、Googleのクローラがで来て、ページ上のリンクをたどることによって、データの束を削除します）一般的な落とし穴を避けるために非常に意図的です。

PATCH（または必要に応じてPOST）を使用する際には、まだいくつかのオプションがあります。ユーザIDに基づいてplayerサービスを作成し、それに状態を更新：利点は羽が自動的に両方の公開ということである

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

：

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

プレイヤーのステータスの変化を受けて、別actionsサービスを作成します。これらのAPIはHTTPとWebSocketを介して自動的に更新され、両方のリアルタイム更新と認証が自動的に取得されます。これらのすべては、通常のExpressで手動で行う必要があります。