PHP url "get“参数处理:响应用户错误的最可用和最可维护的设计是什么？
考虑一个自动构建系统，它将结果存储在数据库中，并响应http 到达请求，通过动态html提供结果的表格显示。很多不同的用户希望看到不同的结果子集，因此PHP中有解析脚本，每个脚本都接受多个可选的过滤参数和值。例如，(我不使用http部分，因此这里没有人实际单击这个示例URL)：
display_results.php?componenent_name=my_comp1&build_type=build_type1&build_owner=fred
即使在某些帮助页面中列出了所有可能的参数及其允许值的列表，当用户正在创建请求URL时，s/他可能没有该文档。相反，它依赖于记忆有效的参数(包括它们的拼写)和允许的值。有时S/他会弄错的。
问题
从最终用户可用性和开发人员可维护性的角度来看，以下哪一个选项是对此类用户错误的最佳响应：
- 忽略无效的参数或值
- 忽略无效参数，无效值不返回任何参数。
- 尽可能多地返回有效的表数据加上一条错误消息(使用正确)
- 只返回一条错误消息(使用正确)
- 尽最大努力进行自动校正
- 其他(解释)
例如，如果数据库包含build_type1和fred的数据，以及名为comp1、comp2和comp3的三个组件的joe，则用户(错误地)写：
display_results.php?name=comp1，comp2&build_type=build_type1&build_owner=john
- 将返回所有结果(因为忽略了错误的参数名称" name "，无效的值"john")
- 不会返回任何信息，因为john没有任何数据
- 将返回build_type1的所有结果，加上消息"no build_owner = john“和”可能您的意思是'component_name'“
- 只会返回"no build_owner = john“和”可能您的意思是'component_name'“
- 为joe返回comp1和comp2的build_type1结果
- 其他(描述)
我将可用性定义为与广泛使用的、行为良好的web应用程序的一致性--如果用户对那些用户满意，他们也会对我描述的应用程序感到满意。
我之所以问这个问题，是因为我是这类脚本的关键用户，提出了大量的增强请求，并希望为进一步的请求获得一些支持。
关于界面的=== -免费表单或“构建者页面”。是的，我说的是自由形式。系统中有一个“构建器页面”，但是(a)它从来没有提供所有用户似乎想要的所有选项，(b)我还无法通过"create“增强请求。
===感谢您所选择的答案--评论中没有足够的篇幅：
谢谢@pygorex1 1！你给出了一个答案，把我的问题放在了一个著名的软件结构-- API中。并给出了一个很好的例子(如果可能是夸大的话;-)违反这些原则的影响。最后，这些脚本的API一直困扰着我，当您提到“自文档化”时，您为我连接了它。困扰我的是，当文档很少(因为更新成本很高)，并且在用户错误(我的！)返回部分结果时，我对系统没有任何了解。“自我文档化”可能是您推荐的错误处理设计最简洁的理由。更容易卖给用户和维护人员！
回答 4
Stack Overflow用户
发布于 2010-12-13 20:16:44
这听起来非常像一个API。一个好API的特点之一是语法清晰一致，这样用户就可以获得可预测的结果。违反语法会导致错误。
即使语法不正确，返回部分结果也是一种糟糕的设计:当用户没有清楚地说明他们想要的数据时，返回的数据很有可能不会有用，或者会被丢弃。更糟糕的是，即使数据不是有效的，数据也可能被视为处于有效的上下文中。
举个例子。该系统设计为忽略无效参数。客户端发送一个comoponent_name参数(component_name拼写错误)，请求输入'A‘类型的所有组件。随后，系统返回所有类型的组件('A'，'B'，'C‘)。(“z”)客户端将这些结果视为“A”类型的所有结果，并根据这些结果进行内部计算和业务逻辑。混乱接踵而至，因为管理层在很大程度上基于这一内部数据分析来做出商业决策，客户首先进入错误的市场部门，然后破产。
现在，这是一个末日场景，但它说明了一点:您可以通过明确定义输入和输出来减轻甚至防止系统错误。
在返回任何数据之前，请验证输入参数。遇到无效参数时，返回解释正确语法的错误消息。这样，系统将自动记录并返回可预测的结果。
Stack Overflow用户
发布于 2010-12-13 19:39:23
如果是我，我将显示尽可能多的有效信息，在错误消息中列出无效参数，然后提供一个没有包含在“有效信息”部分中的有效参数列表。可能是每个有效参数的表单，其中包含一个关联的输入字段。然后，当新的有效信息发生变化时，可能使用AJAX。
Stack Overflow用户
发布于 2010-12-13 19:57:41
我的第一反应是为URL创建一个构建器页面，而不是让用户乱搞。除非有任何理由你不能有一个建设者页面，这是我的建议。这样，您就不必处理通知用户更改的问题。在某些情况下，您还可以选择只提供有效的选项。
https://stackoverflow.com/questions/4432577
复制相似问题
腾讯云开发者
