处理无效 REST API 参数的内部 Java 代码最佳实践
我的同事写了以下 stackoverflow 问题： 有关此主题的其他堆栈溢出问题
这个问题似乎被误解了，我想找到答案，所以我开始这个新问题......希望更清楚一点。
基本上，我们有一个 REST API。我们 API 的用户使用参数调用我们的方法。但有时用户会使用错误的参数来调用它们！也许他们的代码有错误，也许他们只是想和我们一起玩，也许他们想看看我们如何回应，谁知道呢！我们使用 HTTP 状态错误代码进行响应，并可能在 XML 响应中提供无效参数的详细描述。
一切都很好。但在内部我们通过抛出异常来处理这些无效参数。例如，如果某人通过向我们提供其个人资料 ID 来查找 Person 对象，但该个人资料 ID 不存在...我们在查找他们时会抛出 PersonInvalidException。然后我们在 API 控制器中捕获此异常并发送回 HTTP 400 状态错误代码。
我们的问题是...这是最佳实践吗？针对此类用户错误在内部抛出异常？这些异常永远不会传播回用户，这是一个 REST API。它们只会让我们的代码更干净。否则，我们可以在每个 API 控制器中使用验证方法来确保参数都有意义，但这似乎效率低下。我们可能必须在数据库中查找内容两次。或者我们可以返回空值并检查它们，但这很糟糕......
您的想法是什么？
My colleague wrote the following stackoverflow question:
other stack overflow question on this topic
The question seems to have been misinterpreted and I want to find out the answer, so I'm starting this new question... hopefully a little more clear.
Basically, we have a REST API. Users of our API call our methods with parameters. But sometimes users call them with the wrong parameters!! Maybe a mistake in their code, maybe they're just trying to play with us, maybe they're trying to see how we respond, who knows! We respond with HTTP status error codes and maybe a detailed description of the invalid parameter in the XML response.
All is well. But internally we deal with these invalid parameters by throwing exceptions. For example, if someone looks up a Person object by giving us their profile id, but the profile id doesn't exist... we throw a PersonInvalidException when looking them up. Then we catch this exception in our API controller and send back an HTTP 400 status error code.
Our question is... is this the best practice, throwing exceptions internally for this kind of user error? These exceptions never get propogated back to the user, this is a REST API. They only make our code cleaner. Otherwise we could have a validation method in each of our API controllers to make sure the parameters all make sense, but that seems inefficient. We have to look up things in our database potentially twice. Or we could return nulls and check for them, but that sucks...
What are your thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，这是对异常的合理使用；您不能指望您的代码能够从用户错误中恢复。关键是您返回给用户的内容应该足够详细，以便他们能够理解（并纠正）错误的原因。仅仅返回 HTTP 400 或任何其他 HTTP 错误代码不足以让您的用户确定他们做错了什么。
This seems to me to be a reasonable use of exceptions; you can't expect your code to recover from user errors. The key is that what you return to the user should be detailed enough to allow them to understand (and correct) the cause of the error. Simply returning HTTP 400 or any other HTTP error code is not going to be sufficient to allow your users to determine what they are doing wrong.
我认为在检测到请求参数错误时在内部抛出（然后捕获）异常是完全可以的。我尝试过其他方法，但根据我的经验，这种方法效果最好。
我对此的最新尝试是执行以下操作：
RequestFailureException的（未经检查的）异常，该异常将 HTTP 状态代码作为其属性之一。RequestFailureException的子类型。handleException方法，用于记录异常并将其映射到 HTTP 状态代码。doRequest或其他任何内容来捕获异常并使用handleException处理它们。I think that throwing (and then catching) exceptions internally when request parameter error is detected is perfectly fine. I've tried other approaches, but in my experience this works best.
My latest attempt at this is to do the following:
RequestFailureExceptionthat has an HTTP status code as one of its attributes.RequestFailureExceptionfor some of the common cases.handleExceptionmethod in the controller base class that logs exceptions and maps them to HTTP status codes.doRequestor whatever to catch exceptions and process them usinghandleException.我正在 ColdFusion 中实现 REST API，并且使用的异常与您所描述的完全一样。异常是摆脱当前执行状态并向用户传递一致错误消息的好方法。
在您给出的示例中，我更愿意返回状态代码 404。毕竟，Person 是一种资源，如果该人不存在，那么对我来说就是 404。
I'm implementing a REST API in ColdFusion, and I'm using exceptions exactly like you are describing. Exceptions are a great way to get out of whatever state the execution is currently in, and deliver a consistent error message to the users.
In the example you gave, I would prefer to return a status code of 404. After all, a Person is a resource, and if the person does not exist, then that's a 404 to me.