Обработка параметров «получить» в URL-адресе PHP: каков наиболее удобный и удобный дизайн для реагирования на ошибки пользователя?

Question

Рассмотрим автоматизированную систему сборки, которая сохраняет результаты в базе данных и предлагает табличное отображение результатов через динамический HTML в ответ на запросы http GET .Многие пользователи хотят видеть разные подмножества результатов, поэтому в PHP есть сценарии синтаксического анализа, каждый из которых принимает несколько необязательных параметров и значений фильтрации.Например, (я опускаю часть http, поэтому никто здесь на самом деле не щелкает URL этого примера):

display_results.php? Componentenent_name = my_comp1 & build_type = build_type1 & build_owner = fred

Даже если списоквсе возможные параметры и их допустимые значения перечислены на странице справки, когда пользователь создает URL-адрес запроса, у него может не быть такой документации под рукой.Вместо этого, зависит от запоминания действительных параметров (включая их написание) и допустимых значений.Иногда он / она ошибается.

Вопрос

С точки зрения удобства использования для конечного пользователя, а также удобства обслуживания для разработчика, какой из следующих вариантов являетсялучше всего в ответ на такие ошибки пользователя:

1. Игнорировать недопустимые параметры или значения
2. Игнорировать недопустимые параметры, ничего не возвращать для недопустимых значений
3. Возвращать столько допустимых данных таблицы, скольковозможно плюс сообщение об ошибке (при правильном использовании)
4. Возврат только сообщения об ошибке (при правильном использовании)
5. Сделайте лучшую попытку автокоррекции
6. Другое (объясните)

Например, если база данных содержит данные для build_type1 и fred и joe для трех компонентов с именами comp1, comp2 и comp3, а пользователь (ошибочно) пишет:

display_results.php? name = comp1, comp2 & build_type = build_type1 & build_owner = john

1. Возвращает все результаты (поскольку игнорируется неверное имя параметра "name", недопустимое значение "j"ohn ")
2. Не вернул бы ничего, потому что нет данных для john
3. Вернул бы все результаты для build_type1 плюс сообщения" no build_owner = john "и" возможно, вы имели в виду 'component_name' "
4. Возвращает только сообщения "no build_owner = john" и "возможно, вы имели в виду 'имя_компонента'"
5. Возвращает результаты comp1 и comp2 для build_type1 для joe
6. Other (опишите)

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

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

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

=== Спасибо за выбранный ответ - недостаточно места в комментарии:

Спасибо @ pygorex1!Вы дали ответ, который поставил мой вопрос в контексте известной программной конструкции - API.И привел хороший (если, возможно, преувеличенный ;-)) пример воздействия нарушения этих принципов.Наконец, что-то беспокоило меня об API этих скриптов, и когда вы упомянули «самодокументирование», вы связали это для меня.Что меня беспокоило, так это то, что когда мало документации (потому что поддерживать ее в актуальном состоянии дорого) и с частичными результатами, возвращаемыми из-за ошибки пользователя (моя!), Я не узнаю ничего о системе.«Самодокументирование», вероятно, является наиболее кратким обоснованием рекомендованного вами подхода к обработке ошибок.Проще продавать пользователям и сопровождающим!

Answer 1

Звучит замечательно, как API. Одним из отличительных признаков хорошего API является наличие четкого и согласованного синтаксиса, позволяющего пользователям получать предсказуемые результаты. Нарушение синтаксиса должно привести к ошибке.

Возвращать частичные результаты, даже если синтаксис неправильный, - ужасный дизайн: когда пользователь не ясно указывает, какие данные ему нужны, есть большая вероятность, что возвращенные данные не будут полезны или будут отброшены Хуже того, данные могут рассматриваться как находящиеся в допустимом контексте, даже если это не так.

Пример. Система предназначена для игнорирования неверных параметров. Клиент отправляет параметр comoponent_name (опечатка component_name), запрашивая все компоненты типа «A». Впоследствии система возвращает компоненты всех типов («A», «B», «C» ... «Z»). Клиент рассматривает эти результаты как все имеющие тип «А» и основывает внутренние результаты и бизнес-логику на этих результатах. Появляется хаос, так как руководство основывает свои бизнес-решения главным образом на этом анализе внутренних данных, клиент неожиданно вступает в неправильный сегмент рынка и становится банкротом.

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

Перед возвратом каких-либо данных проверьте входные параметры. Если обнаружен неверный параметр, верните сообщение об ошибке, объясняющее правильный синтаксис. Таким образом, система самодокументируется и будет возвращать предсказуемые результаты.

Answer 2

Моим первым инстинктом было бы иметь страницу конструктора для URL вместо того, чтобы позволить пользователям бездельничать. Если только у вас нет причины, по которой у вас не может быть страницы разработчика, это мое предложение. Таким образом, вам не придется сталкиваться с проблемой информирования пользователей об изменениях. У вас также будет возможность в некоторых случаях показывать только действительные параметры.

Answer 3

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

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

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

Answer 4

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