这是第一个话题，所以我打算从最近验证过的内容开始讲！

最近在WebAPI领域经常听到关于RESTful和GraphQL的讨论。
因为网络上有很多关于GraphQL的解释，所以我打算写一写与实际工作或其他体验相比较的观点。

最近REST的要求变得更加严格了。

• API利用側の要件増加

• 利用側がかならずしてもドメイン単位で、利用するとは限らない

• 通信コスト増加 (一部データの利用しかなくても付随データが通信上にながれる)

endpointの増加 (要件ごとに増える)

常见场景下的应对方法

• endpointを増やす

• endpointに必要になった段階で情報を増やす (マイクロサービスでなくなっていく。。。)

こっちの方が多そう

如果不向外界公开，我认为没有必要把它分得那么清楚，但由于通信费用和技术负债的加速性影响，如果可能的话，最好还是把它清晰地分开。

GraphQL和RESTful特点的比较（仅限查询）

在 [GitHub Developer] 上可以使用 explorer 来测试，我认为这样更容易理解。

我尝试体验GraphQL

由于可以在GitHub Developer上使用Explorer功能，所以我认为尝试一下会更容易理解。

现实图像

由于参考了Rubyplus先生的文章，我做了一个样本，所以我想在屏幕上确认一下。

我已经将用到的资料上传到了GitHub上。

没有等级或层次的模式

• Query

[allPeople]内で欲しい情報を定義しています [id, fullName]

Response

Queryで指定した[field]の値のみが返ってきています

Document

Queryとして実行できるものが表示されています。

有层级的模式

• Query

[allPeople]内で欲しい情報を定義しています [id, lastName]
[friends]で異なる情報を指定しています[fullName]

Response

Queryで指定した[field]の値のみが返ってきています
階層化していした[friend]も指定した[field]の値のみが返ってきています.

Document

People(Person)で取得できる[field]を見ることができます

我使用GraphQL时的感想

好处

• ドキュメントメンテしなくてよいので、運用や実装が楽

GraphQLのスキーマを定義するとExplorerで確認できる。

データアクセスが直観的で、ExplorerでQueryが試せるので開発効率がよさそう
スキーマ設定がプログラム指定なので、メンテが楽(XMLとかよりは)

缺点（或者说是令人担忧的问题）

• サーバーサイド実装がちょっと大変になるかも

• Schema定義が肥大化しないアプローチは検討したい

• キャッシュのアプローチを検討

• 　(endpointが一つになるのでCDNが使えない？？)

見えてない課題もあるので、ちょっと一息

总结

与其说是REST和GraphQL的二选一，我更希望能够充分利用它们各自的优势。
由于可能会增加使用返回大量数据的API(臃肿的API?)的场景，
我希望能积极进行验证。

我希望下一次能够写一些关于架构定义和实现部分的内容。