Перья нестандартных методов обслуживания - против правил

Question

Я знаю, что фреймворк Feathers разработан так, чтобы придерживаться REST-дизайна, но я думаю, что у меня есть крайний случай, который стоит немного нарушить. Я хочу создать API-интерфейс музыкального проигрывателя, который позволит программно получать доступ к элементам управления проигрывателя через HTTP и Socket.io.

Игрок, однако, не простой случай get, put, patch, post, а также delete, Один игрок будет создан для каждого пользователя и никогда не будет удален, только изменен. Я хочу, чтобы пользовательские методы, такие как воспроизведение, пауза, setQueue и т. Д., Например, в подчиненных методах PATCH /player/play а также PATCH /player/pause,

Именно так Spotify делает это в своем API, и это имеет гораздо больший смысл, чем отправка PATCH каждый раз запрашивать одну и ту же конечную точку и обновлять данные игрока вручную, т.е. PATCH /player {nowPlaying: {index: newIndex}} перейти к следующей дорожке, где пользователь API должен знать схему данных игрока и как он работает. Вместо этого что-то вроде PATCH /player/next имеет гораздо больше смысла и проще в использовании.

Как реализовать такой сервис, используя API Feathers, не делая все это вручную в экспрессе? Если это невозможно, какой самый удобный способ красиво интегрировать пользовательский экспресс-код с остальной частью приложения?

Answer 1

Хотя Spotify, кажется, делает это таким образом, это не соответствует спецификации HTTP, которая гласит, что GET является безопасным методом, который не должен иметь никаких побочных эффектов, кроме получения данных:

В частности, было установлено, что методы GET и HEAD НЕ ДОЛЖНЫ иметь значение выполнения действия, отличного от извлечения. Эти методы следует считать "безопасными".

Ограничения Feathers в этом отношении очень преднамеренные, чтобы избежать распространенных ошибок (в худшем случае сканер Google входит и удаляет кучу данных, переходя по ссылкам на странице).

У вас все еще есть несколько вариантов при использовании PATCH (или POST, если хотите). Создать player Сервис основан на идентификаторе пользователя и обновляет его состояние:

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

Создать отдельный actions Сервис, который получает изменения статуса для игрока:

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

Преимущество состоит в том, что Feathers автоматически предоставляет оба этих API через HTTP и веб-сокеты, и вы автоматически получаете обновления и аутентификацию в реальном времени для обоих, и все это вам придется делать вручную в обычном Express.