是否为REST API使用单独的控制器？

Question

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

我们可以在当前的控制器中使用withFormat {}但是 在不同的控制器中分离REST功能感觉 有点干净..

通过这种方式，我们可以从当前控制器中单独构建API 我们甚至可以将REST控制器带入另一个应用程序 等

有关此主题的任何想法？任何真实的世界经验 最好的做法是什么？

Answer 1

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

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

我们还希望保留在打开的单独服务器实例上托管REST API的选项。这些服务器将使用完全相同的.war，但具有feature toggles的不同配置设置。

单独控制器的缺点可能是控制器代码的DRYness。虽然这应该是有限的，但是由于IMHO你应该尽可能地保持控制器的精简程度，并将共享逻辑提取到Grails服务或辅助类。

Answer 2

我很快就会使用grails，但到目前为止我对它几乎没有经验。但在我工作的网络应用程序中，我们总是将webservices与控制器代码分开。我们还将REST与SOAP分开。它们的常用方法是服务层。事实上，它感觉更清洁。我们不必在方法

中插入大量if s

Answer 3

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

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