我的API端点接受POST请求。
我使用ServletRequest.getParameter来获取请求参数值。 getParameter可以在请求的字符串或POST表单主体中找到参数值。鉴于此类行为，我的API用户可以发送POST请求，传递参数，如GET请求：
/callApi?paramA=123¶mB=123
虽然，API 应该使用表格来代替URL参数。
我认为没有任何问题。
但从良好的设计角度来看，当用户尝试提出此类请求时，我的API是否会报告错误？
答案 0 :(得分：3)
由于此问题标记在＆＃34; REST＆＃34;下，我将回答这个问题，假设您考虑REST，特别是通过HTTP进行REST，以及＃34;良好的API设计＆＃34;。
HTTP对URI的定义非常明确。最重要的是，URI应该作为标识符。如果您的URI可以更改（并且查询字符串是 URI的一部分），并且具有相同的结果，则从RESTful HTTP的角度来看，这可能表示某些内容已关闭。
在您的示例中，/callApi?paramA=123¶mB=123是资源的（部分）URI。如果您可以使用不同的正文POST到/callApi并具有相同的效果，那么这意味着您拥有在请求正文中标识资源的信息，或者您的URI中包含数据（查询字符串）用于识别资源以外的目的（这是URI应该做的事情）。
如果您不关心RESTful原则，那么当然这可能不适用。如果是这种情况，您可能想要重新提出问题。无论如何，在涉及像你这样的问题时，首先将URI作为ID处理可能会有所帮助。
答案 1 :(得分：0)
我的直觉说“是的没关系”，因为你的服务器端代码应该以相同的方式处理安全性，无论使用的是哪个HTTP动词，还是传递数据的方式。通过擦除输入来避免SQL注入就是一个这样的例子。
我不熟悉你描述的类和方法，但为了保持一致性，我想我会使用POSTed表单数据而不是查询字符串数据，假设你有办法区分两者。
答案 2 :(得分：0)
我会说它会没事的，因为最后当你得到一个参数时，没有默认的方法来确定它的查询字符串还是在Body中。您必须检查查询字符串以查看该参数是否存在，然后相应地采取行动。
我只是将您的文档指定为在正文中执行，而不是查询字符串，并尽可能保持您提交的URL尽可能精简。
我在提供答案时发现this很有用。