REST API дизайн для модификации ресурса: поймать все POST против нескольких конечных точек - PullRequest
Новая
       12

REST API дизайн для модификации ресурса: поймать все POST против нескольких конечных точек

0 голосов
/ 29 апреля 2019

Я пытаюсь выяснить лучшие или распространенные практики для разработки API.Моя проблема в основном такова: 

PUT /users/:id

На мой взгляд, эту конечную точку можно использовать для широкого спектра функций.Я бы использовал его, чтобы изменить имя пользователя или профиль, но как насчет ex, сброса пароля?

С "модельной" точки зрения это может быть флаг, свойство пользователя, поэтому он будет "работать" для отправки модификации.

Но я бы ожидал, что-то вроде

POST /users/:id/reset_password

Но это означает, что почти для каждой модификации я мог создать другую конечную точку в зависимости от значения модификации, то есть 

POST /users/:id/enable
POST /users/:id/birthday
...

или даже 

GET /user/:id/birthday

по сравнению с просто 

GET /users/:id

Так что, в принципе, я не понимаю, когда прекратить использовать один POST / GET и создавать вместо этого разные конечные точки.

Это выглядит как простой вопросЯ просто хочу знать, есть ли какой-то стандартный способ сделать это или какое-то руководство.После прочтения и просмотра примера я все еще не совсем уверен.

1 Ответ

1 голос
/ 29 апреля 2019

Отказ от ответственности: во многих случаях люди спрашивают о REST, когда они действительно хотят - это совместимый с HTTP RPC-дизайн с красивыми URL-адресами. Далее я отвечаю о REST.

На мой взгляд, эта конечная точка может использоваться для широкого спектра функций. Я бы использовал его, чтобы изменить имя пользователя или профиль, но как насчет ex, сброса пароля?

Конечно, почему бы и нет?

Я не понимаю, когда прекратить использовать один POST / GET и создавать вместо этого разные конечные точки.

Действительно хорошей отправной точкой является выступление Джима Уэббера Проектирование на основе доменов для систем RESTful .

Первая ключевая идея - ваши ресурсы не являются вашими объектами модели домена . Ваш REST API - это действительно фасад перед моделью вашего домена, который поддерживает иллюзию, что вы просто веб-сайт.

Таким образом, ваши ресурсы аналогичны документам, которые представляют информацию. URI идентифицирует документ.

Вторая ключевая идея - этот URI используется клиентами для кэширования представлений ресурса, поэтому нам не нужно постоянно отправлять запросы обратно на сервер. Вместо этого мы встроили в HTTP набор стандартных способов передачи метаданных кэширования с сервера на клиент.

Критическим для этого является правило для аннулирования кэша : успешный небезопасный запрос делает недействительными ранее кэшированные представления того же ресурса (т. Е. Того же URI).

Итак, общее правило: если клиент собирается сделать что-то, что изменит уже кэшированный ресурс, то мы хотим, чтобы запрос на изменение перешел на тот же URI.

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

Итак, чтобы позаимствовать ваш пример, у нас может быть представление пользователя на веб-странице. Если бы мы собирались позволить клиенту изменять эту страницу, то мы могли бы продумать множество вариантов использования (включить, изменить день рождения, изменить имя, сбросить пароль). Для каждого из этих поддерживаемых случаев у нас будет ссылка на форму для конкретной задачи. Каждая из этих форм будет иметь поля, позволяющие клиенту описать изменение, и URL-адрес в действии формы, чтобы решить, куда будет отправлена ​​форма.

Так как клиент пытается изменить саму страницу профиля, нам нужно, чтобы каждая из этих форм отправляла обратно на URI страницы профиля , чтобы клиент знал о недействительности ранее кэшированные представления, если запрос был успешным.

Таким образом, ваши идентификаторы ресурсов могут выглядеть следующим образом: 

/users/:id 

/users/:id/forms/enable
/users/:id/forms/changeName
/users/:id/forms/changeBirthday
/users/:id/forms/resetPassword

Если каждая из форм предоставляет информацию /users/:id.

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

...