Браузер отвечает за взаимодействие
Структура страницы определяет, какие элементы доступны человеку, оформление делает их различимыми, а программная логика управляет реакциями. В форме заметки пользователь должен понимать назначение поля, способ отправки и текущее состояние: можно вводить, отправка продолжается или требуется исправление. Проверка в браузере помогает быстро заметить пустое обязательное поле или неверный формат. Но интерфейс не является единственным возможным источником запроса. Поэтому серверу нельзя считать данные надёжными только из-за того, что кнопка разрешала отправку. Полезно заранее описать состояния формы. Пока результат неизвестен, сообщение сохранено преждевременно. При ошибке человеку нужно сохранить возможность исправить данные или повторить действие, не вводя всё заново без необходимости.
Сервер проверяет смысл и полномочия
Сервер получает запрос и решает, какое действие допустимо. Он проверяет данные, пользователя и право изменять конкретную запись. Возможность открыть страницу редактирования ещё не заменяет проверку при сохранении. В условном приложении заметок важны текст, идентификатор записи и её владелец. Если пользователь отправляет изменение чужой заметки, сервер не должен принимать его лишь потому, что указан существующий идентификатор. Проверка формата и проверка права решают разные задачи. После обработки сервер возвращает ответ. Он может сообщить об успехе, неверных данных или другой проблеме. Браузер интерпретирует этот ответ и показывает подходящее состояние. Если смысл ответа и текст интерфейса расходятся, пользователь получает неверное представление о результате даже при работающем соединении.
Сохранение нужно отличать от показа
Изменившийся текст на экране может быть только временным состоянием браузера. Чтобы понять, сохранилась ли заметка, проверяют её получение из хранилища в следующем запросе. Обновление страницы или повторное открытие записи часто обнаруживает различие между демонстрацией и работающим приложением. При этом сбой связи не всегда означает, что действие не выполнено. Запрос мог дойти до сервера, а ответ потеряться. Поэтому повторную отправку важно проектировать так, чтобы она не создавала нежелательные дубли. Конкретный способ зависит от характера операции. Для диагностики полезно двигаться по цепочке: возник ли запрос, что получил сервер, какое решение он принял, что записано и какой ответ показан. Это точнее общего сообщения кнопка сломалась. В учебном проекте достаточно вымышленных данных и собственной тестовой среды. Проверки чужих сайтов без разрешения для изучения этой схемы не нужны.
Попробуйте на практике
Нарисуйте путь сохранения вымышленной заметки и подготовьте проверку каждого этапа без создания публичного сервиса.
- Изобразите четыре участника: пользователь, браузер, сервер и хранилище. Подпишите, какие данные передаются между ними.
- Опишите три состояния интерфейса: ожидание ввода, отправка и подтверждённый результат. Добавьте отдельное состояние ошибки.
- Разберите случаи пустого текста, попытки изменить чужую запись и неизвестного результата из-за связи. Укажите, кто должен принять решение.
- Сформулируйте проверку сохранения: повторно получить запись и сравнить ожидаемый текст с фактическим. Используйте только учебные сведения.
Как проверить результат. Схема отделяет внешний вид, серверное решение и сохранённые данные. Для каждого сообщения об успехе существует конкретное подтверждение, а ошибки не теряются между частями.
Частые вопросы
Можно ли сделать полезный сайт без серверной логики?
Да, для некоторых задач достаточно статических страниц или работы в браузере. Серверная часть нужна там, где требуются соответствующие операции с общими данными и полномочиями.
Почему одинаковую проверку иногда выполняют дважды?
Проверка в браузере помогает пользователю быстро исправиться. Серверная проверка защищает целостность обработки независимо от того, каким способом пришёл запрос.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.