API初心者ガイド

「API」という略語を、これまでに何度も目にしたことがあるかもしれません。オンライン決済やデータアグリゲーターを利用したことがあるなら、知らないうちにAPIを使っています。では、APIとは一体何なのでしょうか。この記事では、APIの仕組み、主なAPIプロトコル、APIの種類について解説します。

APIとは何か、どのように機能するのか？

Application Programming Interface、つまりAPIは、異なるアプリケーション同士の通信を可能にするソフトウェア上の仲介役です。APIは主にシステムのバックエンドで動作するため、目にすることはほとんどなく、使っていることに気づかない場合も少なくありません。 

たとえば、お気に入りのニュースサイトにアクセスして、今日の天気予報を見るとします。他の類似サイトでも、おそらく同じ情報が提供されているでしょう。では、そのデータはどこから来ているのでしょうか。言うまでもなく、ニュース会社が天気予報を作るために自前の気象観測所を持っているわけではありません。代わりに、気象センターからデータを取得しています。同時に、Webサイトはあなたの所在地に合った正確な予報を表示する必要があり、さまざまな場所から何千人もの訪問者が、同時にそのニュースサイトにアクセスしています。開発者やWebサイト管理者が、訪問者ごとに手作業で予報を提供・更新することはできません。そこでAPIが使われます。あなたがニュースを読むためにWebサイトを開くたび、サイトはAPIを通じて気象アプリを呼び出し、所在地の天気を取得して、その応答を表示します。これは、友人に電話をかけて連絡を取ることに似ています。APIは、アプリ同士がやり取りするための「電話番号」のようなものです。

APIが普及し、広く使われているのには理由があります。第一に、APIは開発プロセスを簡素化します。開発者は同じ機能を一から作り直す必要がなく、同じAPIを多くのプロジェクトで利用できます。これにより開発がスピードアップし、時間とコストを節約できます。APIを使うことで、アプリケーション同士が互いの処理に干渉せず、必要なデータだけをやり取りできます。その結果、セキュリティの向上、エラー発生率の低減、プログラムの円滑な動作につながります。 

さらに、APIは基盤となる技術や構造に関係なく、異なるシステム同士の通信を可能にします。ユーザーにとっては、幅広い機能を利用できることを意味します。

APIについて話すとき、私たちは主にWeb API、つまりインターネット接続を必要とするAPIを指します。ただし、一部のAPIは1つのシステムやデバイス内（たとえばコンピューターのオペレーティングシステム）で使用され、インターネット接続をまったく必要としません。この記事では、Web APIに焦点を当てます。

APIの構成要素

舞台裏をもう少し詳しく見てみましょう。APIは、具体的にどのような要素で構成されているのでしょうか。

あらゆるAPIの背後にある主な考え方は相互運用性です。言い換えると、採用する形式をサポートするすべてのプラットフォームが、同じ方法でAPIとやり取りできなければなりません。そのため、開発者が異なり、複数のプロトコルが使われていても、APIの主要な構成要素は同じです。

APIクライアント

APIクライアントとは、リクエストを行うアプリ、ブラウザ、またはソフトウェアのことです。クライアントがリクエストを送信するきっかけはさまざまです。たとえば、ページの更新やボタンの押下といったユーザー操作が、クライアントにリクエスト送信を促すことがあります。データベースクエリなど、自動化されたロジックによって発生する条件も、トリガーになります。

APIリクエスト

APIリクエストは同じ標準に従う必要があります。通常、主に5つの要素で構成されます。

エンドポイント

APIにおけるエンドポイントとは、リクエストの送信先となるURLです。利用可能なエンドポイントや使用すべき形式を知るには、APIベンダーが詳細を記載しているAPIドキュメントを確認する必要があります。通常、エンドポイントには、使用するAPIのドメイン名とバージョンが含まれます。また、さまざまなクエリパラメータが含まれる場合もあります。利用可能なパラメータについても、APIドキュメントに記載されています。

メソッド

リクエストでは、サーバーに何を実行してほしいのかを伝える必要があります。つまり、メソッドとはサーバーに実行内容を指示するコマンドです。メソッドは、使用するAPIプロトコルによって異なります。たとえばRESTプロトコルでは、GET、POST、PUT、PATCH、DELETEなどのHTTPメソッドを利用します。他のプロトコルには、それぞれ独自のメソッドがあります。APIを使用する場合は、そのAPIで使用するプロトコルとメソッドが明記されたベンダーのドキュメントを確認しましょう。

パラメータ

クエリパラメータに加えて、パスパラメータ、ヘッダーパラメータ、リクエストボディパラメータもあります。これらは、認証、リクエストのフィルタリング、受信側サーバーへの必要な詳細情報の受け渡しに必要です。メソッドがサーバーに何をすべきか、たとえばデータを取得することを伝える一方で、パラメータはどのデータを対象にするかを指定するのに役立ちます。

ヘッダー

APIリクエストにおけるヘッダーは、一般的なヘッダーと同様の役割を果たします。つまり、リクエストや希望するレスポンス形式に関する追加データ、要求された操作を実行する権限があることを証明する認可情報、そしてリクエストとレスポンスをどのようにキャッシュするかに関する詳細を提供します。

リクエストボディ

これはリクエストの中心部分であり、主要なデータをリクエストパラメータとして指定する部分です。より理解しやすくするために、小包を想像してみてください。エンドポイントは、小包を届けたい宛先です。パラメータとヘッダーは、受取人の名前や電話番号などのその他の発送情報であり、小包に壊れやすいものが含まれているか、配送料が支払い済みか、または受取人が支払う必要があるかといった追加情報も含まれます。リクエストボディは小包そのもの、つまり箱の中身、あなたが送るものに相当します。リクエストボディに含めるパラメータは、APIベンダーのドキュメントで指定されています。

APIサーバー

APIサーバーとは、リクエストの送信先となるプラットフォーム、ソフトウェア、データベース、またはその他の対象です。APIを提供し、すべてのAPIデータを保存し、リクエストで指定した操作を実行します。

APIレスポンス

リクエストには、それに対応するレスポンスがあります。レスポンスとは、あなたのリクエストに応じてサーバーが送信するものです。レスポンスも複数の構成要素で成り立っています。

ステータスコード

ステータスコードは、リクエストが成功したかどうか、またサーバーがそれを処理できたかどうかを示します。200番台のコードはリクエストが成功したことを意味し、300番台はリダイレクトを意味し、400番台はリクエストに問題があったことを示し、500番台はサーバー側に問題があったことを意味します。

レスポンスヘッダー

レスポンスヘッダーはリクエストヘッダーに似ています。クライアントにCookieを送信し、レスポンスボディに関する詳細を提供します。

レスポンスボディ

レスポンスボディは、要求されたデータを提供する一連のキー/値ペアで構成されます。ただし、レスポンスボディはAPIレスポンスに必須の構成要素ではありません。サーバーにデータの取得・送信を求める場合は、レスポンスボディを受け取ります。一方で、サーバー上のデータを削除または置換しようとする場合、レスポンスボディは表示されず、ステータスコードのみを受け取ります。

APIプロトコル

プロトコルとは、APIがどのように機能するかを定義するルールの集合です。APIにはいくつかのプロトコルが使われています。

REST

REST（またはRESTful、The Representational State Transfer）は、最もよく使われているAPIプロトコルです。ただし、厳密にはプロトコルというよりもアーキテクチャスタイルに近いものです。HTTPプロトコルに依存して、JSONまたはXML形式でデータを転送します。リクエストは互いに独立しており、レスポンスはキャッシュできます。シンプルさと拡張性がRESTの主な利点であり、それがWebサービスやモバイルアプリケーションで第一の選択肢となっている理由です。

一方で、過剰取得や過少取得が発生する可能性があります。つまり、クライアントが要求した以上のデータを受け取ったり、逆に必要なデータをすべて取得できなかったりする場合があります。また、RESTはHTTPプロトコルを使用するため、すべてのデータタイプ、アプリケーション、環境に適しているとは限りません。RESTにはセキュリティ上の懸念もあり、適切に保守されていない場合は脆弱性を抱える可能性があります。

SOAP

Simple Object Access Protocol、つまりSOAPは、RESTよりもはるかに厳格で複雑です。XMLデータ標準を使用し、HTTPやSMTPを含む複数のデータ転送プロトコルをサポートできます。WS-Securityのような高度なセキュリティ機能にも対応しています。主に、金融サービスやSalesforceのようなエンタープライズアプリケーションなど、幅広いユーザーにとっての使いやすさよりもセキュリティと形式性が求められるケースで使用されます。

RPC

リモートプロシージャコールは、JSONおよびXML形式でデータを扱います。ただし、データソースではなくメソッドを呼び出す点で、RESTやSOAPとは大きく異なります。RPCレスポンスは、処理が実行されたか、失敗したかを示します。RPCサーバーを呼び出すとサーバーの状態が変化するため、ベンダーとユーザーの間には高いレベルのセキュリティが必要です。こうした理由から、RPC APIは多くの場合プライベートAPIです。ただし、RPCはデータ転送にHTTP/2プロトコルを利用しますが、これは大半のブラウザでネイティブにサポートされていないため、正しく動作させるには追加の設定が必要になる場合があります。

GraphQL

GraphQLはプロトコルと呼ばれることもありますが、正確にはクエリ言語です。多数のエンドポイントを持つRESTとは異なり、GraphQLは通常1つだけです。GraphQLでは、1つのクエリで複数のリソースを取得できます。ユーザーは必要なデータを指定できるため、過剰取得や過少取得を防げます。一方で、GraphQLにはデータキャッシュに関する課題があります。また、ベンダーはユーザーがクエリを作成できるよう、どのようなパラメータが存在するのかを知らせる詳細なドキュメントを提供する必要があります。

APIの種類

APIを分類する方法はいくつかあります。対象ユーザーで分類する方法もあれば、構造で分類する方法もあります。対象ユーザーで見ると、パブリック、パートナー、プライベートに分けられます。構造で見ると、コンポジット、ユニファイド、マイクロサービス、モノリシックに分けられます。

パブリックAPI

オープンAPIまたは外部APIとも呼ばれるパブリックAPIは、幅広いユーザー向けに設計されています。制限はないか、あってもわずかです。認証や登録が必要な場合でも、そのプロセスは簡単であり、ユーザーはそのAPIを使用するために特別な資格を持つ必要はありません。ただし、オープンAPIでも支払いが必要な場合や、無料アカウントの機能が制限される場合があります。たとえば、Google Maps APIはパブリックAPIです。

プライベートAPI

このタイプのAPIは内部APIとも呼ばれます。企業内のメンバーなど、少人数のユーザーグループを対象としています。このようなAPIにアクセスするには、ユーザーは許可を得る必要があります。安全でなければならないため、認証に時間がかかり、複雑になる場合があります。

パートナーAPI

パートナーAPIは、パブリックとプライベートの中間に位置します。主に2社以上の企業間でデータを共有するために使われるため、このようなAPIにも認証が必要であり、安全性が確保されています。特定のユーザーグループを対象としていますが、そのグループはプライベートAPIの場合よりも大きくなります。このようなAPIを介して共有される情報は重要であり、明らかに幅広い一般向けではありませんが、プライベートAPIを介して共有されるデータほど機密性が高いわけでもありません。

また、4つ目のタイプとしてOpenAPI Standardが言及されることもあります。ただし、これは別のAPIタイプではなく、パブリックAPIを記述するためのフレームワークです。元の名称はSwaggerで、このツールはガイドラインを提供するため、APIの作成と利用がよりシンプルかつ迅速になります。ただし、すべてのパブリックAPIがその標準に従っているわけではないため、パブリックAPIを「オープンAPI」と呼ぶのも正確ではありません。また、プライベートAPIも公開されていなくてもOpenAPI標準を使用する場合があります。

モノリシックAPI

このタイプのAPIは、複雑なシステムへのアクセスを提供する単一のコードベースとして構築されます。利点には、動作の予測しやすさと安定性があります。一方で、多くのデータが結び付いており、変更が予測不能な結果を引き起こす可能性があるため、拡張や更新が困難です。

マイクロサービスAPI

反対に、マイクロサービスAPIでは、それぞれのAPIが異なる特定の目的を果たします。システム全体に影響を与えることなく、更新したり、不要になった部分を停止したりすることが簡単です。ただし、マイクロサービスAPIは膨大な数の個別リクエストを生成します。

コンポジットAPI

ここでコンポジットAPIが役立ちます。コンポジットAPIでは、1回の呼び出しで複数のエンドポイントを利用できます。効率的な呼び出しの組み合わせで必要なデータを取得し、コードの重複を防げます。

ユニファイドAPI

ユニファイドAPIはコンポジットAPIに似ていますが、単一のAPI内の異なるエンドポイントではなく、複数のAPIを利用します。どちらを選ぶかは、ニーズによって異なります。

APIのテストと監視

他のソフトウェアと同様に、APIも安定性、セキュリティ、高いパフォーマンスを確保するためにテストと監視が必要です。APIは手動でテストすることも、自動テストを実施することもできます。APIテストにはいくつかの種類があります。

• 機能テスト – サーバーがリクエストに応答し、レスポンスとデータ形式が正しいことを確認するためのテスト。
• 負荷テスト – トラフィックの急増が発生したときにAPIが正しく動作するかどうかを検証するのに役立ちます。
• セキュリティテスト – 攻撃者に悪用される脆弱性が残っていないことを確認するために必要です。
• 回帰テスト – 変更が加えられた際に、予期しない望ましくない結果が発生しないことを確認するために必要です。
• 耐障害性テスト – DDoS攻撃につながる可能性のあるリクエストなど、潜在的に有害なリクエストに対してシステムがどのように応答するかを確認するのに適しています。

開発者は、開発段階とデプロイ段階の両方でAPIテストを実施します。

まとめ

APIは、テクノロジーを最大限に活用するためのもう1つのツールです。自分では気づかないうちにAPIを使っていることも多いですが、お気に入りのWebサイトやアプリの多くの機能はAPIのおかげで実現しています。一方、DataImpulseは、テクノロジーをわかりやすく解説しています。また、複数のツールを組み合わせることで、より良い結果を得られる場合があります。たとえば、プロキシを使うことで、APIテストをより効果的に行えます。さらに、当社独自のAPIを使えば、当社のプロキシを再販し、DataImpulseとともに収益を得ることもできます。詳しくは、[email protected] までご連絡いただくか、画面右上の「Try now」ボタンをクリックしてください。