PHP url"；获得；参数处理：响应用户错误的最有用和最可维护的设计是什么？

考虑一个自动构建系统，它将结果存储在数据库中，并通过动态html响应http请求提供结果的表格显示。许多不同的用户希望看到结果的不同子集，因此PHP中有解析脚本，每个脚本都接受多个可选的过滤参数和值。例如，（我省略了http部分，因此这里没有人实际单击此示例URL）：

显示\u results.php？组件\u name=my\u comp1&build\u type=build\u type1&build\u owner=fred

即使在某些帮助页面上列出了所有可能参数及其允许值的列表，当用户创建请求URL时，他/她可能手头没有该文档。相反，这取决于记忆有效参数（包括它们的拼写）和允许的值。有时他/她会弄错

问题

从最终用户可用性和开发人员可维护性的角度来看，以下哪种选项最能应对此类用户错误：

忽略无效的参数或值

忽略无效参数，对无效值不返回任何内容

返回尽可能多的有效表数据和错误消息（使用正确）

仅返回一条错误消息（使用正确的用法）

尽最大努力进行自动校正

其他（解释）

例如，如果数据库包含名为comp1、comp2和comp3的三个组件的build_type1和fred与joe的数据，并且用户（错误地）写入：

显示\u results.php？name=comp1，comp2&build\u type=build\u type1&build\u owner=john

将返回所有结果（因为忽略了错误的参数名称“name”，无效值“john”）

将不返回任何内容，因为没有john的数据

将返回build_type1的所有结果以及消息“no build_owner=john”和“也许您指的是‘component_name’”

只会返回消息“no build\u owner=john”和“也许您的意思是‘component\u name’”

将返回joe的生成类型1的comp1和comp2结果

其他（描述）

我将可用性定义为与广泛使用、性能良好的web应用程序的一致性——如果用户对这些应用程序感到满意，他们也会对我描述的应用程序感到满意

我问这个问题是因为我是这类脚本的关键用户，提出了大量的增强请求，并希望获得进一步请求的支持

=== 关于界面——自由格式或“生成器页面”。是的，我说的是自由形式。系统中有一个“构建器页面”，但（a）它从来没有提供所有用户似乎都想要的所有选项，（b）我无法通过“创建永久链接”增强请求

=== 感谢您选择的答案--评论空间不足：

---

谢谢@pygorex1！您给出的答案将我的问题置于一个著名的软件结构——API的上下文中。并就违反这些原则的影响给出了一个很好的例子（也许有些夸张）。最后，这些脚本的API一直困扰着我，当你提到“自我文档化”时，你帮我连接了它。让我困扰的是，当文档很少（因为更新成本很高）并且在用户错误（我的！）时返回部分结果时，我对系统一无所知。“自我记录”可能是您推荐的错误处理设计最简洁的理由。更容易销售给用户和维护人员

如果是我，我会显示尽可能多的有效信息，在错误消息中列出无效参数，然后提供未包含在“有效信息”部分的有效参数列表。

---

可能是每个有效参数的一个表单，其中包含一个关联的输入字段。然后，AJAX可能会在新的有效信息发生变化时出现。

我的第一反应是为URL创建一个构建页面，而不是让用户胡乱处理。除非有任何原因，你不能有一个建设者页面，这是我的建议。这样，您就不必处理通知用户更改的问题。在某些情况下，您还可以选择仅显示有效选项

根据部署中应用程序的预期行为，我建议跳转到400错误请求，或仅使用提供的数据显示结果集，并显示某种标志，通知用户某些限制参数已被忽略

您必须评估返回的数据的特殊性，以及是否必须始终返回数据集以代替错误。如果这是一个仅为用户使用而收集数据的应用程序，例如搜索目录，那么使用提供的参数并仅限制这些参数当然是可以接受的

---

然而，出于安全考虑，许多大型web应用程序（例如Amazon）将确保包含所有参数，以迫使用户在站点中使用UI组件，而不是篡改url（因为篡改url的人通常没有最佳意图）如果删除node参数或ie参数（这决定了要显示的字符集），可以在Amazon上看到一些示例。使用省略或伪造的参数跳转请求可以很好地保持对不需要的输入的控制。

这听起来非常像API。一个好的API的一个特点是具有清晰一致的语法，这样用户就可以得到可预测的结果。违反语法将导致错误

即使语法不正确也返回部分结果是一种糟糕的设计：当用户没有清楚地说明他们想要什么数据时，就会出现错误