web-services - 是否对 REST API 使用单独的控制器的建议？

Question

我们正在为我们的应用程序计划一个 REST api，并试图决定是否应该为 REST 功能实现单独的控制器。

我们可以在我们当前的控制器中使用 withFormat{}，但在不同的控制器中分离 REST 功能感觉更清晰。

通过这种方式，我们可以将我们的 API 与当前控制器分开构建，我们甚至可以将 REST 控制器带入另一个应用程序等。

对这个主题有什么想法吗？任何关于最佳实践的实际经验是什么？

Answer 1

我们最近面临同样的决定，我们决定为 REST API 使用单独的控制器。

单独控制器的优点包括更清晰/更清晰的控制器操作以及以后支持不同版本的 REST API 的可能性。

我们还希望保持在单独的服务器实例上托管 REST API 的选项处于打开状态。这些服务器将使用完全相同的 .war，但功能切换的配置设置不同。

单独控制器的一个缺点可能是控制器代码的干燥性。尽管这应该是有限的，但由于恕我直言，您应该使控制器尽可能薄，并将共享逻辑提取到 Grails 服务或帮助程序类。

Answer 2

我很快就会使用 grails，但到目前为止我还没有什么经验。但是在我工作的 Web 应用程序中，我们总是将 Web 服务与控制器代码分开。我们还将 REST 与 SOAP 分开。他们的常用方法将在服务层中。确实，感觉更干净。我们不必在if方法中插入很多 s

Answer 3

对于给定的资源，我会使用一个控制器，该控制器基于上下文（接收或请求的媒体类型——SOAP、JSON、XML 等）与服务层接口。这样，你就有了一个真正统一的资源标识符，可以接受并返回各种媒体类型，控制器不需要知道用户想要对什么资源执行什么方法以及涉及什么媒体类型。

例如，服务层可能返回具有诸如“toXml”、“toSoap”或“toJson”等方法的对象。然后，您可以只要求服务层执行任何操作，并在请求的媒体类型上使用 switch 语句来返回请求的信息，或者默认情况下抛出 406 Not Acceptable 状态代码。对于不安全或幂等事务，对象可能具有给定媒体类型的构造函数或工厂方法，然后您只需要求服务层对该对象执行任何操作。