API服务器

在开发JSON API服务器时，客户端发送HTTP请求，服务器以JSON数据结构作为响应返回。

关于这样的API设计，过去一直认为REST是最好的选择。由于Facebook提出的GraphQL已经在Github API v4中得到了应用和验证，所以我进行了一些调查。

REST API复习

Ruby on Rails的资源表示法也采用了这种特点。

RESTの原則

(Uniform Interface) 情報の操作は、すべてHTTPメソッド(GET, POST, PUT, DELETE)でおこなう。
(Addressability) リクエストのＵＲＬによって、提供する情報がひとつに定まる。
(Stateless) サーバーは状態をもたない。
(Connectability) 応答する情報に、別の情報へのリンクを含めることができる。

RESTの性質

GETリクエストは再実行に対して安全である。
PUT等のリクエストは再実行しても指示以上の動作をおこさない（べき等と呼ぶ）
サーバーはリソースごとに固有のURLをもち、メソッドによって操作が決まる。

RESTの実際

とはいえ、必要な情報をかき集めるためには、普通はindexなどのREST外URLも使うよ。

GraphQL 的 API

在GraphQL中，响应的数据结构是由请求来决定的。对于REST一直致力于的统一接口和可寻址性，将会进行修改。

GraphQLの原則

あらゆるGraphQLのリクエストと、応答を引き受ける、唯一のURLを提供する。
仕様化されたクエリ言語で情報を請求したり、操作を請求したりする。

GraphQLの性質

個々のリクエストにあわせて通信内容を絞り込むので、最小限の通信サイズとなる。
必要な多数のリソースを、関連づいた形式でまとめて取得する。
書き込み系処理の仕様変更をサーバーで吸収しやすい。

GraphQL与REST互相对应。

我尝试想象通过REST和GraphQL访问的API服务器。

在这种情况下，开发者需要编写以下类似表格的代码（如果采用graphql-ruby IDL，代码的编写可能会更简单）。

在REST中，我们会将处理逻辑写在同一个控制器类的方法中。可以将共同部分整理到私有方法中，或者进行重构使其归属于模型。

相比之下，在GraphQL中，处理逻辑会被写在字段的解析函数中。可以将共同部分主要重构到模型中。

此外，为了解决多次进行数据库查询的问题，我们可以通过实现符合lazy_resolve接口的缓存来进行调优。

GraphQL 的实施方法

要在Ruby on Rails中引入GraphQL。

宝石 “graphql”
宝石 “graphql-batch”
宝石 “graphiql-rails”

rails generate graphql:install --batch --schema=#{AppName}Schema
rails g graphql:function #{function_name}
rails g graphql:mutation #{mutation_name}
rails g graphql:loader

写作方式

请参考以下示例：https://github.com/joe-re/sample-graphql-on-ruby
创建模式、查询类型和变异类型。
在实际工作中，最好为每个模型提供一个文件来管理它们的字段和类型定义。

• Schema

query

field

type
argument
resolve

mutation

field

type
argument
resolve

提及

http://graphql-ruby.org/ -> GraphQL Ruby 的官方网站。
https://github.com/graphql/graphiql -> GraphQL 官方的 GraphiQL GitHub 页面。
http://mgiroux.me/2015/getting-started-with-rails-graphql-relay/ -> 关于使用 Rails GraphQL Relay 的教程，链接为 mgiroux.me。