RESTful способ выполнения проверки
Работая над интерфейсами SOAP RPC, я борюсь с тем, как подходить к вещам таким образом, который соответствует шаблону проектирования RESTful.
Например. Если у нас есть мастер регистрации для нового клиента, который имеет 3 страницы.
Первая страница для имени /DOB. Вторая страница для адреса. Третья страница для других материалов. Окончательная сводная страница, с которой клиент завершает регистрацию.
Публикация нового клиента будет выполняться с последней страницы сводки, так что это очевидно, но как бы вы порекомендовали выполнить проверку данных, введенных на каждой из страниц.
Данные на странице 1 не являются ресурсом клиента, это частичный ресурс клиента, который требует проверки на соответствие некоторым бизнес-правилам на стороне сервера (например, DOB и уникальное имя пользователя - или что-то еще, что нелегко реализовать в проверке клиента JavaScript).
Результатом ошибки проверки может быть предложение альтернативных имен пользователей, а не просто ответ кода состояния 200/400.
Проект RPC будет вызовом метода ValidatePage1.
Но речь идет о действии "Подтвердить" для элемента данных, и я пытаюсь использовать ресурсы и результаты действия.
Это плохой дизайн для API, чтобы иметь вызовы типа REST и RPC, или бывают случаи, когда этот подход действителен, когда имеет дело с проверочными "действиями", которые на самом деле являются действиями, а не публикациями / получениями ресурсов и т. Д. ValidateDOB, ValidateAge, ValidateAddress и т. Д.
1 ответ
Например. Если у нас есть мастер регистрации для нового клиента, который имеет 3 страницы.
Первая страница для имени /DOB. Вторая страница для адреса. Третья страница для других материалов. Окончательная сводная страница, с которой клиент завершает регистрацию.
Если бы вы делали это как HTML, протокол, вероятно, выглядел бы примерно так - вы бы использовали закладку, чтобы найти ресурс, который предоставил бы вам представление пустой формы.
Вы должны заполнить форму, отправить ее; браузер просматривает элементы управления в форме, чтобы обнаружить целевой ресурс формы, создать представление данных вашей формы и отправить это представление на сервер. Сервер проверит ваши входные данные и либо вернет вам (а) представление состояния приложения с указанными ошибками, либо (б) представление состояния приложения с заблокированными действительными полями и новую форму для сбора следующей страницы данные. Гиперссылки в этом новом представлении могут идти в то же место, что и предыдущая форма, или в другом месте.
В какой-то момент вы предоставляете представление формы с полными и действительными данными, и это приводит вас к новому состоянию приложения, когда вам больше не нужно заполнять эти формы.
Если вы сделаете это, у вас есть ОТДЫХ.
А как насчет кодов статуса? Что ж, каждый раз, когда форма отправляется, ресурс отвечает с представлением нового состояния приложения, поэтому вполне уместно ответить 200 (ОК), даже в случаях, когда проверка не удалась, и мы отправляем работу обратно пользователь для перезаписи.
Обратите внимание, что этот дизайн совсем не зависит от:
- Какие идентификаторы вы используете для своих ресурсов
- Соответствуют ли задействованные ресурсы сущностям в вашей доменной модели
- Изменяют ли ресурсы, участвующие в проверке формы, состояние вашего домена