在 Grails 应用程序中实现 REST API [英] Implement a REST API in a Grails app
问题描述
我想知道让 Grails 应用程序提供可被 Web 服务使用的 RESTful API(主要是一些 CRUD 操作)的最佳方法是什么，例如当您想为基于浏览器的应用或其他任何应用构建相应的 iOS 应用时.
I was wondering what would be the best approach to make a Grails app offer a RESTful API (some CRUD actions mainly) that can be used by a web service, e.g. when you want to build a corresponding iOS app to your browser-based app or anything else.
我想在我的 Grails 应用程序中构建一个单独的部分，它接受来自 www.mywebapp.com/api/someAction 的调用，以便我可以重用服务层.那么我将如何进行 URL 映射?只有一个大的 ApiController 听起来不太时髦.
I thought of building a separate part in my Grails application that takes calls from www.mywebapp.com/api/someAction so that I can reuse the Service layer. How would I do the URL mapping then? Only having one big ApiController does not sound very groovy.
或者有什么我不知道的更好的方法?这种方法必须支持诸如OAuth之类的东西来验证调用 Web 服务的用户.
Or is there any better approach I did not know of? This approach must support something like OAuth to authenticate the user who is calling the Web service.
推荐答案
Grails 绝对可以提供 REST api，但是这样做的难度取决于成熟(也就是 RESTful)您希望 API 是什么.
Grails can definitely provide a REST api, but the level of difficulty in doing so varies depending on how mature (aka. how RESTful) you want the API to be.
获得 RESTfullness 的基本级别，在其中您可以使用完整的 HTTP 动词和利用 HTTP 响应代码来操作资源的 json 或 xml 表示，这非常容易.有 3 个主要部分来实现这一点:
Getting a basic level of RESTfullness, where you are manipulating json or xml representations of resources using the full span of HTTP verbs and leveraging the HTTP response codes, is pretty easy. There are 3 main pieces to getting that in place:
以下是我如何在最近的项目中编写 URL 映射以支持更多 RESTful URL 的示例:
Here's an example of how I wrote my URL mappings on a recent project to allow for more RESTful URLs:
// RESTful list mapping
name restEntityList: "/$controller"(parseRequest: true) {
action = [GET: "list", POST: "save"]
}
// RESTful entity mapping
name restEntity: "/$controller/$id"(parseRequest: true) {
action = [GET: "show", PUT: "update", POST: "update", DELETE: "delete"]
constraints {
id matches: /\d+/
}
}
Grails 处理内容协商的 3 种不同方式使该框架非常灵活，允许您支持更广泛的客户端，这些客户端可能无法设置 Accept HTTP 标头等内容.
The 3 different ways that Grails can handle content negotiation make the framework very flexible, allowing you to support a much broader range of clients who may not be able to set things like the Accept HTTP header.
您可以使用 withFormat 块基于客户端表明他们想要什么.这种强大的功能还可用于对您的 API 进行版本控制，就像 Github 所做的一样.
HTTP 已经内置了一个很好的响应机制，允许您利用架构中的先天能力，例如可缓存性和幂等操作.虽然某些网络浏览器不能很好地处理某些响应代码，但使用您的 API 的客户端应用程序可以使用它们来大大简化其内部代码.
HTTP already has a great response mechanism built into it that allows you to leverage innate abilities in the architecture, like cacheability and indemnipotent operations. While some web browsers don't handle certain response codes very gracefully, client applications using your API can use them to greatly simplify their internal code.
干休
使您的应用程序保持 RESTful 并同时保持 DRY 的最佳方法之一是尽可能多地利用控制器脚手架，因为所有域对象的 CRUD 本质上都是相同的.本文关于制作默认控制器更多 RESTful，以及这篇文章 简化默认控制器都是从脚手架获得更多动力的重要资源.
DRY REST
One of the best ways to make your application RESTful and keep it DRY at the same time is to leverage the controller scaffolding as much as possible, since CRUD is essentially the same for all domain objects. This article on making the default controller more RESTful, and this article on simplifying the default controller are both great resources for getting more power from the scaffolding.
一旦你达到了这一点，你的 grails 应用程序就有了一个非常实用的 REST API.您可以执行所有基本的 CRUD 操作，而且资源相当容易使用.
Once you get to that point, you have a pretty functional REST API for your grails application. You can do all basic CRUD operations and the resources are fairly easy to work with.
然而，通往真正的 RESTful 超媒体 API 的阶梯的下一个层次要达到要困难得多.解决这个问题是 Grails 的路线图，但目前相当痛苦.这些部分是:
The next levels of the ladder to a true RESTful hypermedia API, however, are much harder to attain. Fixing this is on the road map for Grails, but currently it's rather painful. These pieces are:
- 超媒体资源
- 内容类型
- 版本控制
谢天谢地，有一个插件，它使定义自定义编组器变得非常容易，这使我们能够公平地轻松解决剩下的三个 REST 难题.
Thankfully, there is a plugin that makes defining custom marshallers very easy, which allows us to fairly easily cover those three remaining pieces of the REST puzzle.
最后，还有保护整个事物的方面.一般来说，Spring Security 会在保护用户访问方面保持良好的状态到你的api.由于大多数 API 访问来自应用程序，而不是用户可见，因此基本或摘要式身份验证通常是最简单的方法.有一个基于 Spring 构建的 OAuth 插件安全.我没有亲自使用它，所以我不能保证它的稳定性，但对我来说它看起来很不错.
Finally, there is the aspect of securing the whole thing. In general, Spring Security will hold you in good stead as far as securing user-access to your api. Since most API access is from an application, and isn't user-visible, basic or digest authentication is usually the simplest way to go. There is an OAuth plugin that builds on Spring Security. I have not personally used it so I can't vouch for it's stability, but it looks pretty good to me.
总的来说，Grails 足够灵活且功能强大，可以非常非常好地执行 REST，但尚未完成工作以使其开箱即用地执行 REST.
In general, Grails is flexible and powerful enough to do REST very, very well, but the work has not been done yet to make it do REST cleanly out-of-the-box.
这篇关于在 Grails 应用程序中实现 REST API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
