Это все еще идиоматический POST, если конечная точка одновременно удаляет ресурс и создает его?

Question

Я изо всех сил пытался написать конечные точки API RESTful и недавно столкнулся со сценарием, который я не уверен, как справиться. Я создал модель с ограничением по времени для действия и конечной точкой, которая должна:

1. создать ресурс для пользователя, если он не существует, или
2. удалить старый ресурс и создать новый, если он существует и срок его действия истек

Моя текущая реализация - это конечная точка, которая обрабатывает эту логику во время создания ресурса, но что-то в выполнении как удаления, так и создания во время запроса POST кажется неправильным. Делать множественные запросы для выполнения одной и той же задачи также кажется неправильным, потому что кажется, что это может привести к ошибке, если пользователь заканчивает с двумя ресурсами или чрезмерно многословным сообщением, если есть запрос на создание, который терпит неудачу, запрос на удаление и запрос создание снова. Каким был бы идиоматичный и надежный способ приблизиться к этому?

Answer 1

Чтобы сначала ответить на вопрос заголовка, часть удаления для поведения POST не является идиоматической, поскольку POST обычно не предназначен для замены, НО я не верю, что это строго запрещено, поэтому в зависимости от вашей ситуации (как описано ниже),POST или PUT оба являются приемлемыми подходами.

Когда ваш случай должен использовать PUT:

Если вы знаете идентификатор, тогда вам лучше всего сделать:

PUT /your/resource/path/<id>

Почему: POST означает больше строго для нового создания ресурса.По моему мнению, PUT чаще используется в ситуациях, когда вы хотите «создать или заменить», что соответствует вашим требованиям настолько близко, насколько вы получите.

Вот хороший источник, который обсуждает и поддерживает то, что яговорю:

PUT против POST в REST

И хороший отрывок:

Метод PUT запрашивает, чтобы вложенный объектхраниться под предоставленным Request-URI.Если Request-URI ссылается на уже существующий ресурс, вложенный объект СЛЕДУЕТ рассматривать как модифицированную версию, находящуюся на исходном сервере.Если Request-URI не указывает на существующий ресурс и этот URI может быть определен как новый ресурс запрашивающим пользовательским агентом, сервер-источник может создать ресурс с этим URI. "

Когда ваш случай должен использовать POST:

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

Заключительное примечание:

Если вы не знаете идентификатор всоздание, то вы не могли бы даже вернуться к УДАЛИТЬ → (пере) POST, потому что для УДАЛИТЬ, вы должны ориентироваться по идентификатору. И если вы удаляете без идентификатора, то у вас есть другие "это идиоматический" quответы на вопросы.