使用Java异常的内部REST API的用户错误？(Use Java exceptions inte

我们有一个REST API是伟大工程。我们正在重构，并决定如何在内部通过我们的API的用户处理错误。

例如，用户需要指定其中应考虑的“1984”的值的“电影” URL参数，“撞车”，或“化身”。首先，我们检查，看它是否有一个有效的价值。

什么是最好的办法，如果电影参数是无效的？

从内部的方法之一返回null，并在主API调用方法检查空
从内部方法抛出一个异常，并赶在主API方法例外

我相信这会令我们的代码更具可读性和优雅的使用异常。但是，我们不愿意因为我们会被抛潜在用户，因为API输入错误的许多例外，我们的代码可能是完美的。这似乎并不正确使用异常。如果有沉重的性能损失有例外，这将使感与堆栈跟踪需要被收集，等等，那么我们花费不必要的资源时，我们需要做的是告诉用户该参数是错误的。

这是REST API的方法，所以我们不会propogating的例外API的用户，我们也不会想即使可能。

那么什么是最好的做法吗？使用丑陋空或使用Java的异常处理机制？

Answer 1:

都不是。

最关键的是传递一个错误的参数是不是特殊的条件。抛出异常的情况除外。（这是，这里不再使用它们的原因，而不是性能。）

你应该使用类似Spring的资料验证API进行绑定，在传递的参数。

一个REST API的客户不应该接收空或例外。他们应该得到，让他们发生了什么事情不暴露这些细节的想法的错误消息。 “对不起，我们无法找到那部电影”还是空？与第一次去，倒手。

Answer 2:

如果一个无效的请求进来（如验证错误），你应该表现出400状态码（错误的请求）。

在内部我也创建例外层次结构将映射到HTTP休息域（见错误情况的状态码）。

实施例（简体和被检查异常）：


class RESTBaseException extends RuntimeException{
  int statusCode;

  public RESTBaseException(int statusCode){ this.statusCode=statusCode; }

  //if no statusCode passed we fallback to very broad 500 server error.
  public RESTBaseException(){ this.statusCode=500; }  
}

class RESTValidationException extends RESTBaseException{

   RESTValidationException(){
      super(404);
   }
}

您可以通过驶过的错误消息，构造函数来使客户更乐意上面的例子中延伸。

后来，你应该抓住这些异常有专用的异常处理程序在你的servlet处理程序链（测绘的状态码servlet响应）。例如Spring MVC中有对于不错的异常处理解决方案。

通常我不喜欢营造一种深刻的自定义异常hierachies但我认为REST API层他们是OK（因为状态代码后传播）。