Rest API требует дополнительных операций - как структурировать?

Question

Мои заявки на участие в торгах требуют, чтобы пользователи регистрировались, прежде чем они смогут использовать эту услугу, и сделать это, создав приложение. Начальный план интерфейса следующий:

POST /Users/Applications - Создает приложение и возвращает уникальный идентификатор.

GET /Users/Applications/{id} - Извлекает существующее приложение.

PUT /Users/Applications/{id} - Обновляет существующее приложение.

DELETE /Users/Applications/{id} - Удаляет существующее приложение.

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

• ActivateApplication - когда все данные в системе с помощью PUT Теперь я хочу, чтобы пользователи, чтобы активировать их применение. Это не просто вопрос обновления статуса приложения с помощью PUT, есть несколько дополнительных заданий, которые должны быть сделаны для активации приложения, такого как отправка по электронной почте отдела HR. сообщить им, что поступило новое заявление.

• PrintApplication - при вызове с клиента печатает приложение на офисном принтере. (Не идеальный пример, но у вас есть идея, я уверен!)

0 Как я могу структурировать интерфейс REST для обработки этого типа запроса? Возможно, что-то вроде этого ...

POST /Users/Applications/{id}/print 

POST /Users/Applications/{id}/activate 

... для активации Я меняю состояние, поэтому считаю, что мне нужно использовать POST. Я понимаю, что REST - это документы, но как я могу структурировать свой API, когда мне нужно выполнять операции с документами, а не просто получать и обновлять сам документ?

Answer 1

This Статья Мартина Фаулера гласит, что: Некоторые люди неправильно делают переписку между POST/PUT и созданием/обновлением. Выбор между ними весьма отличается от этого.

Когда я пытаюсь решить между PUT и POST я следовать следующему правилу:

PUT -> идемнотентные

POST -> Не Идемпотентный

Идемпотентный означает, что там нет разница между выполнением одной и нескольких операций. Данные БД будут одинаковыми после первой операции и после каждой из других операций.

В случае не-идемпотентных операций каждая выполненная операция изменяет данные в БД.

Вот почему PUT обычно используется для операций UPDATE и POST для CREATE. Но это не правильное правило.

Возвращаясь к вашему вопросу, по-моему, вы правильно используете POST как не идемпотентное действие, потому что несколько вызовов ActivateApplication отправят несколько писем.

Отредактировано

Как @elolos прокомментировал, после единого ResponsAbility принципа, отправка электронной почты должен быть другой не напрямую ОТВЕТСТВЕННОСТЬ связано обновить состояние. Обработать событие, когда свойство изменилось, чтобы инициировать процессы, такие как отправка писем, было бы лучшим подходом. Таким образом, операция ActivateApplication может быть идемпотентной и вызываться с использованием метода PUT Http.