2

我的 API 端点接受 POST 请求。

我ServletRequest.getParameter用来获取请求参数值。getParameter可以在请求的字符串或 POST 表单正文中找到参数值。鉴于这种行为，我的 API 用户可以发送 POST 请求，传递参数，如 GET 请求：

/callApi?paramA=123&paramB=123

虽然，API应该接受表单值而不是 URL 参数。

我看不出有什么问题。

但是从一个好的设计角度来看，当用户尝试提出此类请求时，我的 API 是否应该报告错误？

4

3 回答 3

3

由于这个问题被标记在“REST”下，我将假设您考虑 REST，特别是通过 HTTP 的 REST 作为“良好的 API 设计”来回答这个问题。

HTTP 对什么是 URI 有一个非常清晰的定义。最重要的是，URI 应该用作标识符。如果您的 URI 可以更改（并且查询字符串是URI 的一部分）并且具有相同的结果，那么从 RESTful HTTP 的角度来看，这可能表明某些事情发生了变化。

在您的示例中，/callApi?paramA=123&paramB=123是您的资源的（部分）URI 。如果您可以/callApi使用不同的正文 POST 并具有相同的效果，那么这要么意味着您在请求正文中具有标识您的资源的信息，要么您的 URI 中有用于其他目的的数据（查询字符串）识别资源（这是 URI 应该做的）。

如果您不关心 RESTful 原则，那么这当然可能不适用。如果是这种情况，您可能需要重新标记问题。无论如何，当涉及到像您这样的问题时，首先将 URI 视为 ID 会很有帮助。

于 2013-09-24T04:29:45.753 回答
0

我会说这很好，因为最终当你得到一个参数时，没有默认的方法来确定它的查询字符串还是在正文中。您必须检查查询字符串以查看参数是否存在于其中，然后采取相应措施。

我只会让您的文档指定在正文中而不是在查询字符串中执行此操作，并尝试使您提交的 URL 尽可能精简。

在提供答案时，我发现这很有用。

于 2013-09-24T01:48:39.597 回答
0

我的直觉说“是的，这很好”，因为您的服务器端代码应该以相同的方式处理安全性，而不管使用的 HTTP 动词或数据传递的方式。通过清理输入来避免 SQL 注入就是这样一个例子。

我不熟悉您描述的类和方法，但为了保持一致性，我想我会使用 POSTed 表单数据而不是查询字符串数据，假设您有任何方法可以区分两者。

于 2013-09-24T01:38:49.157 回答