GCPユーザのためのGoogle APIs入門

# はじめに
みなさんは下記のリポジトリを目にしたことはあるでしょうか。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/287774/a05d656c-f6c4-c87f-1a49-2351a96d5c70.png)
[Google APIs](https://github.com/googleapis)

主にGoogle Cloud（以下、GCP）のクライアントライブラリが格納されているリポジトリで、任意のプログラミング言語からGCPを触ろうと思うと、基本的にはこちらのリポジトリにお世話になるかなと思います。

ここで疑問に思うのが「Google APIsとは何？」です。
Googleが開発者に提供するWeb API（以下、API）の総称なのでしょうか。
はたまた、GoogleのAPIの内、一部のAPIに関する名称なのでしょうか。
[Wikipedia英語版のGoogle APIs記事](https://en.wikipedia.org/wiki/Google_APIs)もありますが、詳しくは何も書いてありません。
GCPのAPIを表す[Cloud APIs](https://cloud.google.com/apis?hl=ja)というカテゴリーもあり更に混乱します🤔

個人的に、GCP開発者はその全ての操作をAPI越しに行うわけなので、GoogleのAPIを把握しておくことは非常に重要だと感じています（もちろん、コンソールを使う場合も裏側でAPIを叩いています）。

この記事では、

- Google APIsとは何か
- Google APIsの歴史
- Google APIsの豆知識

等が分かるようにまとめました。
（※調査して帰納的に導いた結論を多分に含むため、もしより詳細な情報お持ちな方がいらっしゃれば教えていただけると幸いです🙇‍♂️）

# Google APIsとは何か？
まず結論から言ってしまうと、**GCPやFirebase、Google Play、Workspaceといった、私たちが普段触るGoogleのAPIは全てGoogle APIsに該当する**と考えて問題ないです。
[API Strategy & Practice Conference 2017](https://apistrat17.sched.com/event/BiDC/googles-api-methodology-and-style-guide-hong-zhang-google)にてHong Zhang（GoogleのAPI基盤を統括）が発表したスライドに「Google APIsとは何か？」の答えが載っていました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/287774/c4dcf135-cddb-bba4-32ce-2e87e6a16ca0.png)
[Google API Design & Practice](https://static.sched.com/hosted_files/apistrat17/74/Google%20API%20Design%20%26%20Practice.pdf)

ここで重要なのは「Hosted on *.googleapis.com domain」、つまり`*.googleapis.com`にホストされたGoogleのAPIこそがそのままズバリGoogle APIsの定義とされています。
実際に、例えばCloud RunのAPIは`run.googleapis.com`ですし、Firebase Authは`identitytoolkit.googleapis.com`[^1]、Gmailは`gmail.googleapis.com`といったように、確かに`googleapis.com`のサブドメインになっています。
（前述の[Cloud APIs](https://cloud.google.com/apis?hl=ja)についても基本的に`googleapis.com`のサブドメインになっていることから、Google APIsの内Google Cloudに関するAPI即ち「Google APIs ⊃ Cloud APIs」の関係性だと考えられます）

Googleが開発者向けにAPIを公開したのは2002年からなのですが、黎明期は仕様が統一されておらず様々な仕様が乱立した状態でした。
そこで仕様の統一に関する模索が始まり、[OAuth](https://developers.google.com/identity/protocols/oauth2)やリクエストの形式等に関する統一された仕様であるGoogle APIsが確立していった流れのようです。

# Google APIsの歴史

|年  |できごと  |
|---|---|
|2002  |Google最古のAPI「Google Web API」を発表  |
|2010 - 2012  |2010年頃からGoogleのAPIを統一化する流れが加速。Google I/Oにて、APIが統一されていない問題から、新世代APIへの移行を開始していることを発表。今日のGoogle APIsの土台が作られ始める  |
|2014  |API design guide（Google APIsのデザインガイドライン）がGoogle社内で導入 |
|2015  |[Google APIsのGitHubリポジトリが公開](https://news.ycombinator.com/item?id=9312315) |
|2019  |API Improvement Proposalが一般公開 |

順番に見ていきましょう。
まず、2002年にGoogle最古のAPIである「Google Web API（後にGoogle Search APIと名称変更）」が公開されます。
これはSOAPベースのAPIで、Googleの検索エンジンをAPI越しに利用できるものでした。
認証方式としては、同時に公開されたGoogleアカウントが担っていたようです。

>Google Web APIs (Google SOAP Search API に名称が変更されました)
>
>[Google Web APIs を使ってみる](https://www.antun.net/tips/soap/google.html)

>また、副次的な点ではあるが、今回新たに「Google Account」がGoogleAPIの利用のために公開されたことも興味深い。Google Accountの説明ではこのアカウントが将来的にGoogle Group、Google AdWords、Google StoreなどGoogleが提供するさまざまなサービスにアクセスするためのアカウントになる可能性を示しており、今後どのような利用方法が提示されるのか興味があるところだ。
>
>[米GoogleがWebサービスに～「Google Web API」を公開](https://internet.watch.impress.co.jp/www/article/2002/0412/googapi.htm)

その後、マッシュアップ界隈で幅広く使われたGoogle Maps API（2006年）や、約25種のAPIプラットフォームである[Google Data APIs](https://codezine.jp/article/detail/2642)（2008年）がリリースされ、GoogleのAPIエコシステムは拡充されていきました。
拡充しつつも、さまざまな設計が入り混じった様相を呈していきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/287774/55634561-ccfc-586a-b7cf-38ff91a7c0ed.png)
[Google G Data Reading And Writing Data On The Web](https://www.slideshare.net/QConLondon2008/google-g-data-reading-and-writing-data-on-the-web)


そんな中、2010年前後よりAPI仕様が統一されていない問題点や、JSONではなくXMLを採用している問題点が社内で指摘され始め、新世代のAPIへの移行を開始し始めます。
この新世代のAPI基盤こそが、今日のGoogle APIsに続くモノです[^2]。

この頃の様子は[Google I/O 2010 - How Google builds APIs](https://www.youtube.com/watch?v=nyu5ZxGUfgs)や[Google I/O 2011: Life of a Google API Developer](https://www.youtube.com/watch?v=62RxWSzQ-0o)、[The next generation of google APIs](https://www.slideshare.net/profyclub_ru/the-next-generation-of-google-ap-is-ade-oshineye)を観ると詳細を確認できるかと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/287774/70963fb1-8306-4b15-fe4f-40d5db9d51d8.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/287774/e7ab1d9d-62ba-d282-3f5f-1508938916bd.png)

[How Google builds APIs（アーカイブ）](http://web.archive.org/web/20120204034623/https://www.google.com/events/io/2010/sessions/how-google-builds-apis.html)

Google APIsの目指す思想は、

```sh
- Easy to learn
- Easy to use, even without documentation
- Hard to misuse
- Easy to read and maintain code that uses it
- Sufficiently powerful to satisfy requirements
- Easy to extend
- Appropriate to audience

# How to Design a Good API and Why it Matters
# https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/32713.pdf
```

といったように「シンプルでありながら使いやすい」が一貫したデザインになっています。

2014年頃からAPI設計ガイド（API design guide）がGoogle社内で導入され、Google APIsをデザインする上で用いられていきます。

2019年にはAPI設計ガイドをより詳細に説明したAPI Improvement Proposal（AIP）が一般に公開され、Google APIsの仕様について私たちもより深く知ることができるようになりました。

>これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。
>
>[API設計ガイド](https://cloud.google.com/apis/design?hl=ja)

>Today we're sharing many of our API Design guidelines via AIPs (basically Python's PEPs for API style). Check out http://aip.dev for more information and feel free to file bugs if you find them.
>
>[@jgeewax - 2019年5月14日](https://twitter.com/jgeewax/status/1128005271069110272
)

# Google APIsの仕様
https://twitter.com/apstndb/status/1157201935520296960?s=20&t=1awsEMncTC-Putj3GjKNSw

Google APIsの仕様を知りたい場合は、前述の[API設計ガイド](https://cloud.google.com/apis/design?hl=ja)や[API Improvement Proposals](https://google.aip.dev/)を読むとGoodです。

# Google APIsの一覧
基本的にGoogle APIsは[Google API Discovery Service](https://developers.google.com/discovery/)をもとにしたAPIエクスプローラーに載っています。

https://developers.google.com/apis-explorer/

この一覧を見ると如何にGoogle APIsが多く存在するかが分かります。

# Google APIsに関わる人物
[Introduction to Google Developer Relations](https://www.slideshare.net/chanezon/introduction-to-google-developer-relations)によると、Google APIsの発展に寄与した人物としてインターネットの父Vint CerfやGoogle最古のAPIを作ったNelson Minar、Google Mapsを作ったBret Taylor、開発者向けAPIに携わった[Chris Dibona](https://medium.com/the-lindberg-interviews/interview-with-googles-open-source-director-chris-dibona-ba68d7e395e7)やGreg Steinらが挙げられています。

API Improvement Proposalsには、2022年9月現在のテクニカルリードがEric Brewerであること、インフラはHong Zhang、設計はJJ Geewaxが見ていることが書いてあり、もしGoogle APIsをより深く知りたくなった場合はこの界隈の発信をキャッチアップすると良さそうです。

>The current TL (technical lead) for APIs is Eric Brewer; he has delegated some responsibilities for API Infrastructure to Hong Zhang (@wora) and API Design to JJ Geewax (@jgeewax).
>
>[AIP Purpose and Guidelines](https://google.aip.dev/1)

# Google APIsとコンソール
現状、基本的にGoogle APIsはGoogle Cloudコンソール内の「APIとサービス」で管理することができます。
また、Google CloudコンソールにてAPIを有効化することで利用を開始できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/287774/f008644e-ff2a-c5cd-b780-c50ed5600843.png)

Twitter等の各種プラットフォームにはAPIコンソールがありますが、Googleの場合は[APIコンソール](https://support.google.com/googleapi)がGoogle Cloudのコンソールと統合されているためです。

過去のブログを漁ると分かることですが、元からGoogle Cloudコンソールと統合されていたわけではありません。
2010年の記事[Introducing the Google APIs Console and our latest API updates](https://developers.googleblog.com/2010/11/introducing-google-apis-console-and-our.html?m=1)で「APIコンソールを作りました！」と発表した際のURLは`https://code.google.com/apis/console/`です。

>We’re announcing the Google APIs console,
>
>[Introducing the Google APIs Console and our latest API updates](https://developers.googleblog.com/2010/11/introducing-google-apis-console-and-our.html?m=1)

2016年の記事では、APIコンソールのドメインは`console.developers.google.com`となっています。

https://developers-jp.googleblog.com/2016/04/google-api.html

# Google APIsとSOAP / REST
前述のように、GoogleのAPIはSOAPベースのGoogle Web APIから始まっています。
その後、Google Web APIに携わっていたNelson Minarが[Why SOAP sucks](https://www.somebits.com/weblog/tech/bad/whySoapSucks.html)なる記事を出す等、脱SOAPの動きが進みます。
理由のひとつとしてはXMLを採用しているため取り扱いがしんどいということも挙げられました。

>SOAPが（標準としては）死んだ云々は新鮮な話ではなく、SOAP is Comatose But Not Officially Dead!に代表されるようにかなり前から「もはや死に体で、死亡宣告が行われていないだけだ」という見方はあった。ただ今回、Googleが実質的に息の根を止めたというように受け止めましたね
>
>[GoogleがSOAPにトドメを刺した日](http://sevendegrees.blogspot.com/2006/12/googlesoap.html?m=1)

>エンタープライズを念頭において定義された SOAP では，プラットフォームに依存しないプロトコルが採用されています。この SOAP XML には冗長性があり，JavaScript や Ruby などの Web 技術で扱うには少なからぬ苦痛を伴います。
>
>[SOAP から REST へ - その方法と意義](https://www.infoq.com/jp/articles/rest-soap/)

>Googleは当初、XMLを共通言語として利用し、異なるサーバ間でデータをやり取りする考えだった。だが、XMLを使った作業は複雑になる場合がある。さらに重大な問題として、XMLで作成された大容量のファイルは、アプリケーションのパフォーマンスを低下させる可能性がある。
>
>[グーグル、XMLに代わるデータ交換ツール「Protocol Buffers」をオープンソース化](https://japan.zdnet.com/article/20376854/)

その後Google Data APIではRESTベースのものを採用する等、GoogleのAPIにおいてもRESTが主流になっていきます。
現在のGoogle APIsはプロトコルバッファをもとに吐き出されたgRPCベースのAPIと、それを変換したRESTベースのものが準備されています。
SOAPはRPCなので、RPC→REST→RPC（gRPC）みたいな変遷を辿っていることになりますね。

>This repository contains the original interface definitions of public Google APIs that support both REST and gRPC protocols.
>
>[googleapis/googleapis](https://github.com/googleapis/googleapis)

# 企業が公開するWeb APIの歴史
https://twitter.com/joris_hensen/status/956785041115361280

[Intro to APIs: History of APIs](https://blog.postman.com/intro-to-apis-history-of-apis/)も示すように、セールスフォースやeBayからWeb APIを公開してDevRel的な動きを推進する流れは本格化していったようです。

[^1]: ちなみになぜFirebase Authのドメイン名がidemtitytoolkit.googleapis.comなのかというと、元々Google Identity Toolkit APIという名のソーシャルログインを可能にするAPIがあったようです。そのAPIと相乗りする形で実装されたからだと考えられます。ref. [Google API 第23回](https://vintage.ne.jp/blog/2015/12/740)
[^2]: 実際にこのあたりの動画で新仕様APIとして解説されているGoogle Buzz APIもgoogleapis.comドメインになっている