案件でWeb API関連を担当することになったので自己理解・整理の為に残していきます。
適宜、追記(もしくは別記事)・更新して行こうと思いますので、
ご指摘・ご指南・参考になるサイトや書籍などありましたら、Twitter(@ptyanz)の方までご連絡頂けると幸いです。
IT部門1年目にも分かるような感じで記載できたらなと思っています。
そもそもWeb APIって？
Web APIの用途としてどのように利用されているか探してみると色々出てきますが、
一言で広義的に表すなら
「HTTPプロトコルでやりとりするアプリケーション間のインターフェース」
となります。（名前のまんま）
この意味を初めて聞いたとき、「これなら既に作ってるぞWeb API」と思いました。（社会人何年目だったか。。。）
HTTPとは
名前のまんまとは言ったもののHTTPとはなんぞやって人向けに簡単に、
HTTP（Hypertext Transfer Protocol）は、Web上でのデータの送受信に使われるプロトコルです。HTTPは、クライアントとサーバーの間でリクエストとレスポンスを交換することにより、Webページや画像、動画などのリソースを取得するために使用されます。
HTTPは、以下のような特徴を持ちます。
ステートレス: HTTPは、ステートレスであるため、各リクエストは互いに独立しています。これは、Webサーバーがクライアントの状態を保持する必要がないことを意味しています。
プロトコルの柔軟性: HTTPは、プロトコルの柔軟性に優れています。HTTPは、データを送信するための方法について厳密な規定を定めていないため、HTMLや画像、音声、動画など、様々な種類のデータを扱うことができます。
ネットワーク層に依存しない: HTTPは、ネットワーク層に依存しないため、TCP/IP、ATM、IPX/SPX、AppleTalkなどの異なるネットワーク上でも使用することができます。
簡単なセキュリティ実装: HTTPは、簡単にセキュリティ機能を実装することができます。HTTPSプロトコルを使用することにより、データの暗号化やサーバー認証を行うことができます。
HTTPは、WebアプリケーションやWebサイトで広く使用されており、主要なWebサーバー、Webブラウザー、Webフレームワーク、WebAPIなどがHTTPをサポートしています。HTTPのバージョンは、HTTP/1.0、HTTP/1.1、HTTP/2などがあります。最新のHTTP/3では、UDPプロトコルをベースにしています。
インターフェースとは
インターフェース、結構ざっくりとしたニュアンスで使われがちな言葉。
「何かと何かをつなぐ部分」くらいの意味合い。
例えば、ユーザーインターフェース（UI）という言葉がありますが、
「ユーザー」と「コンピューター」をつなぐ部分（画面など）になります。
なので、Web APIは、アプリケーションとアプリケーションをつなぐものですね。
Web APIの種類
参考書籍によれば、次の３つの観点で整理するとよいそうです。
・認証の有無
・内部向け（非公開）or外部向け（公開）
・フォーマットとプロトコル
認証の有無(主に外部向け（公開）)
認証なしのAPIとしては、情報が公開されているもの、RSSやAtomなどのフィードが認証なしの公開APIの例になります。
認証なしのAPIはWebクローラーなども含めて大量のアクセスがあるため、負荷に対する対応が必要となります。
認証ありのAPIとしては、アクセスできるユーザーを限定するため、
ユーザー認証自体は任意のままで、アクセストークンを得るための仕組みを仕様としてまとめたOAuth
を利用したものが多い印象です。
認証の話は別途記事に書こうと思っています。
内部向け（非公開）
内部向けの段階
a.Webブラウザ上で実行されるAjaxからのリクエスト先
b.モバイルアプリケーションやゲーム端末、組み込み向け
c.他組織との合意の下にインターネット越しにリクエストを受けるもの
d.内部ネットワーク内でマイクロサービスやミドルウェアの間で呼び出されるもの
フォーマットとプロトコル
フォーマットの主流はJSON、以前はXMLもよく使われていた。
（関わっているプロジェクトはXMLを採用しそうなのだが、、、）
HTTPのほかにも、RPCプロトコルのWeb APIとして、
JSON-RPCやXML-RPC、SOAPなどがあります。
HTTP/2を利用したgRPCもあります。
Web APIの呼び出しインターフェースの形式
REST API
REST(Representational State Transfer)とは、
Roy Fieldingが、2000年に博士論文で紹介したWebアーキテクチャの設計原則
REST APIは、Representational State Transfer（表現型状態転送）の略語で、Webサービスの設計アーキテクチャの1つです。RESTは、HTTPプロトコルをベースに設計されており、Web上でリソースを表現し、リソースに対する操作を提供するAPIを作成するための設計原則を提供しています。
REST APIの主な特徴は以下の通りです。
軽量性: REST APIは、HTTPプロトコルをベースにしており、軽量で効率的な通信を実現できます。
拡張性: REST APIは、HTTPプロトコルに基づいているため、既存のWeb技術を活用することができます。また、URI（Uniform Resource Identifier）を使用して、リソースを識別するため、拡張性が高いとされています。
キャッシュ可能性: REST APIは、HTTPプロトコルを使用しているため、キャッシングが可能です。これにより、ネットワーク帯域幅を節約し、パフォーマンスを向上させることができます。
クライアント-サーバーアーキテクチャ: REST APIは、クライアントとサーバーを分離することができます。これにより、スケーラビリティが高くなり、クライアントとサーバーの実装を独立して進めることができます。
ステートレス: REST APIは、ステートレスであるという特徴があります。これは、リクエストごとに必要な情報を含めるため、セッション情報などをサーバー側で保持する必要がないことを意味しています。
REST APIは、Webアプリケーションやモバイルアプリケーションなど、さまざまなアプリケーションで利用されています。主要なWebサービスプラットフォームやSaaSサービスには、REST APIが提供されていることが一般的です。
GraphQL
GraphQLは、Facebookが開発したオープンソースのデータクエリング言語および実行エンジンであり、Web APIの設計に使用することができます。以下に、GraphQLの概要を説明します。
GraphQLは、REST APIの代替として使用されることがあります。REST APIは、リソース単位でデータを取得することができますが、GraphQLは、クライアントが必要なデータだけを取得することができるように設計されています。GraphQLは、シンプルなクエリ言語を提供し、必要なデータのみを取得することができます。これにより、不要なデータを送信することを防ぎ、ネットワーク帯域幅を節約することができます。
GraphQLは、クライアントが必要なデータを指定することにより、サーバーサイドの実装の詳細を隠蔽することができます。これにより、サーバーサイドの実装を変更する必要があっても、クライアント側での変更を最小限に抑えることができます。また、GraphQLは、リアルタイムでデータを取得するためのサブスクリプション機能を提供するため、リアルタイムなWebアプリケーションの開発にも使用することができます。
GraphQLは、Web APIの設計に使用することができます。GraphQLサーバーは、データを提供するためのスキーマを定義し、クライアントは、GraphQLのクエリを使用して、必要なデータを取得します。また、GraphQLは、言語やフレームワークに依存しないため、多くのプログラミング言語やフレームワークで使用することができます。
以上が、GraphQLの概要です。
以下にいくつかの具体例を挙げます。
Facebook – GraphQLは、Facebookが開発した技術です。Facebookは、GraphQLを内部的に使用しており、FacebookのモバイルアプリケーションやWebサイトなど、多くのプロダクトにおいてGraphQLを採用しています。
GitHub – GitHubは、GraphQL APIを提供しており、GraphQLを使用してリポジトリやプロジェクトのデータにアクセスできます。
Shopify – Shopifyは、GraphQLを採用して、ショップのデータをクエリするAPIを提供しています。
Yelp – Yelpは、GraphQLを採用して、ビジネス情報の検索やレビューの取得などを行うAPIを提供しています。
Coursera – Courseraは、GraphQLを採用して、オンラインコースの情報を取得するAPIを提供しています。
The New York Times – The New York Timesは、GraphQLを採用して、記事やニュースの情報を提供するAPIを提供しています。
これらは、GraphQLが広く採用されているいくつかの例です。
gRPC
gRPCは、Googleが開発したオープンソースのリモートプロシージャコール（RPC）システムです。以下の点で特徴があります。
- プロトコルバッファを使用して、高速で効率的な通信を実現
- バイナリ形式での通信をサポートし、HTTP/2をベースに実装されたプロトコルを使用
- 言語に依存しないプラットフォーム間の相互運用性をサポート
- クライアント側とサーバー側で生成されたスタブ（ラッパー）コードを使用して、直感的で簡単なAPIを提供
gRPCは、マイクロサービスアーキテクチャでの使用に適しています。マイクロサービスアーキテクチャは、アプリケーションを独立した小さなサービスに分割し、それらを組み合わせて大規模なシステムを構築するアプローチです。各サービスは独自のデータベース、API、ビジネスロジックを持ち、独立して開発、デプロイ、スケールできます。
gRPCは、サービス間の通信に使用されるため、マイクロサービスアーキテクチャで使用することができます。各サービスは、必要に応じて別のサービスを呼び出し、相互に通信することができます。gRPCは、高速かつ効率的なバイナリプロトコルを使用して通信するため、大量のデータを送信する必要がある場合に最適です。また、言語に依存しないプラットフォーム間の相互運用性をサポートするため、異なるプログラミング言語で開発されたサービス間でも通信できます。
したがって、gRPCはマイクロサービスアーキテクチャで使用することができ、分散システムの構築に役立ちます。
以下は、gRPCを使用している一部のサービスの例です。
Google Cloud Platform: Googleは、gRPCを使用して、Google Cloud Platformの多くのサービスを実装しています。例えば、Bigtable、Pub/Sub、Cloud Spannerなどがあります。
Netflix: Netflixは、gRPCを使用して、マイクロサービスアーキテクチャでの通信を実装しています。また、gRPCを使用して、Netflixが開発したOSSである、gRPCエコシステムの一部である、gRPC-Gatewayを提供しています。
Square: Squareは、Square RegisterというPOSシステムでgRPCを使用しています。gRPCを使用することで、高速な通信とデータの高速化を実現しています。
Cockroach Labs: Cockroach Labsは、分散SQLデータベースであるCockroachDBをgRPCを使用して実装しています。gRPCを使用することで、分散システム間での高速かつ効率的な通信を実現しています。
CoreOS: CoreOSは、gRPCを使用して、Kubernetesのコンポーネントを実装しています。Kubernetesは、gRPCを使用してAPIサーバーと各コンポーネント間で通信を行います。
マイクロサービスアーキテクチャ
モノリシックなシステムをマイクロサービス化し、各マイクロサービスをWeb APIで連携させるようなリプレイスが近年増えてきています。
丁度、この記事を書くきっかけになったのも、そういうリプレイスのお仕事があったため。
マイクロサービスアーキテクチャについては、別記事に書こうと思っています。
マイクロサービスアーキテクチャは、複雑なアプリケーションを小さなサービスに分割するアプローチです。これにより、個々のサービスを独立して開発、デプロイ、スケールできます。各サービスは、単一の機能を提供するために設計され、他のサービスと連携して完全なアプリケーションを提供します。
マイクロサービスアーキテクチャの中核となる考え方は、個々のサービスが小さく、疎結合であることです。これにより、サービスは個別に開発、デプロイ、スケールでき、また、変更に対して強く、全体的な可用性が高くなります。このアプローチは、モノリシックなアプリケーションの複雑さを解消し、迅速かつ柔軟な開発、テスト、デプロイを実現することができます。
マイクロサービスアーキテクチャは、APIを介して各サービスを公開し、外部のアプリケーションやサービスとの連携を可能にします。また、各サービスは独自のデータベースを持ち、必要に応じてデータを共有できます。
マイクロサービスアーキテクチャの実装には、いくつかの課題があります。例えば、分散システムの管理や、各サービスのデプロイとバージョン管理、APIの設計とドキュメンテーションなどがあります。しかし、これらの課題を解決するために、コンテナ技術やクラウドプラットフォームなどの新しいツールが利用されるようになっています。
参考書籍・サイト
【書籍】
・Software Design 2021年2月号
【サイト】
コメント