RESTful моделирование нажатий кнопок, которые вызывают действия на стороне сервера для ресурса

Question

Я запускаю новое веб-приложение, которое мы хотим сделать РЕСТАЛЬНО.Теперь пришло время приступить к проектированию взаимодействий, и что-то вроде базового в REST поставило меня в тупик.Я пытаюсь найти лучший способ обеспечить несоответствие импеданса между REST и OO, не падая по скользкому склону RPC.Позвольте мне привести (надуманный) пример.

Виджеты могут быть созданы, изменены и затем отправлены на рассмотрение.

Чтобы изменить виджет с идентификатором 123, пользователь делает PUT для/ myapp / widget / 123 и новые данные формы.Сервер переупаковывает все данные формы в виде POJO и передает их на уровень логики для проверки и последующего сохранения, вызывая WidgetManager.update (widgetPojo).

Чтобы отправить виджет для проверки, пользователь нажимает кнопку, который также делает PUT в / myapp / widget / 123, но теперь у данных формы просто есть одно поле, статус «отправлено» (я не отправляю все данные формы снова, просто поле, которое я хочу изменить).Однако теперь серверу необходимо вызвать другой бизнес-объект, WidgetStateManager.updateState (123, «submit»), который собирается выполнить некоторую другую специализированную обработку в дополнение к обновлению состояния.

Итак, пытаясь быть RESTful, я смоделировал как обновления виджетов, так и действие отправки на проверку в виде PUT для одного и того же URL-адреса, / myapp / widget / 123.Итак, теперь в моем коде на стороне сервера мне нужно выяснить, что означает конкретный запрос PUT с точки зрения бизнес-функций и, следовательно, какие бизнес-функции нужно вызывать.

Но как я могу надежно определитькакую функцию вызывать, просто проверяя значения в данных формы?SOOO заманчиво передать поле «action» вместе с данными формы со значением типа «update» или «submit for review» в PUT!Затем сервер может выполнить переключение на основе этого значения.Но это, конечно, не RESTful и не более чем переодетый RPC.

Просто не кажется безопасным или масштабируемым, чтобы вывести, какая кнопка была нажата, просто изучив данные формы с кучей if-then-все в рестлете.Я могу представить десятки различных действий, которые можно выполнить с виджетом, и, следовательно, десятки if-then-elses.Что мне здесь не хватает?Моя интуиция говорит мне, что я не смоделировал свои ресурсы правильно, или мне не хватает определенной абстракции ресурса, которая помогла бы.

Answer 1

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

Создать виджет:

POST для / rest / widget (возвращает «123»)

(«Метод POST используется для запроса, чтобы исходный сервер принял объект, включенный в запрос, в качестве нового подчиненного ресурса, идентифицируемого Request-URI в строке запроса.»)

Проверить виджет 123:

POST to / restapi / validator / 123

(Ресурс является условным «валидатором» для виджета 123.)

Обновление виджета 123:

PUT to / restapi / widget / 123

Отправить виджет 123 на рассмотрение:

POST to / restapi / reviewqueue

(есть только одна очередь просмотра, поэтому нет необходимости в /123.)

Удалить виджет:

УДАЛИТЬ в / restapi / widget / 123

Answer 2

несколько баллов;

Домен интерфейса службы! = Домен реализации

Ресурсы, предоставляемые вашей службой, не обязательно должны быть напрямую реализованы как объекты в вашем коде.Интерфейс (службы) не является реализацией.

Для Put & Post требуется все внешнее состояние

При выполнении необходимо указать все состояние ресурса.ваши обновления (вы сказали, что вы предоставляете только изменения - это PATCH, а не PUT).

Моделирование изменений состояния с помощью ресурсов коллекции

Иногда лучшесмоделировать изменение состояния как ресурс коллекции.В вашем примере вам действительно нужно рассмотреть ресурс «Просмотр» со связанной «Очередью обзора» или , чтобы добавить атрибут «Требуется проверка» в виджет.

Подход 1. Контейнер для «очереди просмотра»

Наличие объекта «Просмотр» позволит легко перечислять виджеты для просмотра, назначать ресурсы для просмотраetc

GET / review-queue - для получения списка виджетов, которые необходимо просмотреть

POST / review-queue - создание новой записи обзора (с указанием только идентификатора, имени виджета иURL-адрес обратно к виджетам)

DELETE / review-queue / X - удалить из очереди, когда виджет был просмотрен

Я бы использовал этот подход, если бы существенное поведение было связанос «очередью просмотра», например, разрешениями, связанными с добавлением виджета для просмотра, несколькими очередями просмотра и т. д.

подход 2. Атрибут «Требуется проверка»

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

Когда виджет создан, его состояние включается в качестве атрибута 'needs-review', для которого установлено значение False.Очевидно, вам нужно все внешнее состояние в POST

Когда виджет нуждается в проверке, ПОЛУЧИТЕ его и ВЕРНУТЬ его обратно с обновленным «потребностей-обзором».Опять же, вам нужно все внешнее состояние в PUT

. При отображении виджетов для просмотра используйте

GET / widgets /? Needs_review = true

Бедный старый RPC

Вы упомянули RPC в своем последнем абзаце и, хотя это не по теме, я не могу не комментировать ...

Я думаю, что, возможно, мы все виноваты в том, что обвиняем RPC во всех бедах мира.Реальная проблема с RPC состоит в том, что он нацелен на то, чтобы сделать удаленные вызовы функций прозрачными для программиста, скрывая сценарии сбоев и пытаясь сделать удаленный вызов эквивалентным на языке реализации в качестве стандартного вызова функции.Как старый программист CORBA (который страдал от той же проблемы), я могу оценить, как REST исправляет эту ошибку.

Другие моменты из вашего поста

Вы не можете определить, какой метод вызывать, не изучив новое состояние и не сравнив его с существующим состоянием.

Вы должны проверить новое состояние, прежде чем делать что-либо еще, передавая любые ошибки обратно отправителю.

Из вашего последнего абзаца, я думаю, вы уже это знаете - извините.

Chris

Answer 3

Трудно сказать, не зная больше о домене, но неплохо было бы иметь коллекционный ресурс «для проверки». Поскольку ваши ресурсы проходят через процесс, вы можете перемещать их из одного списка в другой. В качестве дополнительного преимущества вы также получаете возможность выполнить GET в этих списках, чтобы выяснить, какие ресурсы находятся в этом конкретном состоянии.