開発エンジニアのNAHO.Sです。
アプリケーションやツールを開発する際に、Web APIを利用することは珍しくありません。
Web APIには、Google API、LINE API、Slack API、X API(旧Twitter API)といった有名なものもあり、現在様々な種類が公開されています。これらを上手く利用することで、開発工数を削減することも可能となります。
しかし、実際にAPIを使ってみると、こんな悩みに直面したことはありませんか?
「既存のAPIを使ってみたけど、欲しいデータが取得できない」
「APIリクエストの制限数に達してエラーになってしまう」
多くのWeb APIは便利な一方、以下のような様々な制限事項が設けられています。
- レート制限
(例:1分間に100リクエストまでの送信しかできない) - 認証、認可の制限
(例:認証がないと特定のエンドポイントへのアクセスができない) - 機能の制限
(例:有料版を使用しないと追加機能が利用できない) - 商業利用の禁止
(例:特定のビジネスモデルやアプリケーションでの利用ができない) - etc…
このような制約があると、既存のAPIのみでは理想の機能を実現できないこともあります。そのような場合、独自のWeb APIを設計・開発することが有効な解決策になります。
そこで、独自のWeb APIを開発する際にどのような設計を行うとよいのか、何に気を付けるべきかについて、4回に分けてご紹介していきます。
本記事では第1弾として、Web APIの基本概念から各メソッドの種類についてご説明します。
1. WebAPIの基本概念
まずはWeb APIとは何か、ご紹介します。
1.1. Web APIの仕組み
そもそも「API(Application Programming Interface)」 とは、ソフトウェアやシステム間で機能やデータをやり取りするための「仕組み」や「ルール」のことを指します。
これを踏まえたうえで、Web APIとは、インターネットやイントラネットを介して異なるシステム間でデータや機能をやり取りするためのインターフェースになります。
例えば、「サービスA」のデータを利用したい開発者がいるとします。開発者は「サービスA」が提供するAPIを使用してリクエストを送信します。
このリクエストを受け取った「サービスA」は、リクエスト内容に基づいてデータや結果をレスポンスとして返します。
このように取得したレスポンスを用いることで、開発者は自分のツールと他のアプリケーションやサービスを連携させることが可能となります。
独自のWeb APIを開発する場合も仕組みは同じです。しかし、上図の「サービスA」が提供している部分の設計(リクエストやレスポンスの形式、内容など)を行う必要があります。
1.2. HTTPメソッド
Web APIでは、HTTP(HyperText Transfer Protocol)を使用してリクエストとレスポンスのやり取りが行われています。
HTTPリクエストには「HTTPメソッド」が含まれており、これによりサーバーに対して何をしたいかを伝えることができます。
「HTTPメソッド」で操作の種類を示すため、複数のメソッドがあります。
メソッド | 概要 | 重要度 |
GET | リソースの取得 | ★★★ |
POST | リソースの送信 | ★★★ |
PUT | リソースの更新 | ★★★ |
DELETE | リソースの削除 | ★★★ |
PATCH | 部分的なリソースの更新 | ★★ |
HEAD | ヘッダー情報の取得 | ★★ |
OPTIONS | サポートされているメソッドの確認 | ★★ |
TRACE | リクエストのループバックテスト | ★ |
CONNECT | プロキシサーバーとのトンネリング | ★ |
重要度の★が多いメソッドほどよく使用されます。
それぞれのメソッドについて、詳しく説明していきます。
1.2.1. GET :リソースの取得
GETメソッドは、サーバーからデータを取得するために使用されます。通常、データの読み取り専用として使用するため、サーバーの状態を変更しません。
最も基本的なHTTPメソッドの一つで、ウェブブラウザがウェブページを表示する際にも使用されています。
1.2.2. POST :リソースの送信
POSTメソッドは、サーバーにデータを送信して新しいリソースを作成するために使用されます。
送信されたデータはリクエストのボディ部分に含まれるため、フォームの送信や新しいデータの追加に使用されます。
1.2.3. PUT :リソースの更新
PUTメソッドは、指定されたリソースを更新するために使用されます。
リクエストボディに含まれるデータを使用して、指定されたリソース全体を置き換えます。リソースが存在しない場合は新しいリソースを作成することもあります。
1.2.4. DELETE :リソースの削除
DELETEメソッドは、指定されたリソースを削除するために使用されます。リソースの削除要求をサーバーに送信します。
1.2.5. PATCH : 部分的なリソースの更新
PATCHメソッドは、リソースの部分的な更新を行うために使用されます。
PUTメソッドがリソース全体を置き換えるのに対して、PATCHメソッドは指定された部分のみを更新します。主に部分的な変更や修正が必要な場合に利用されます。
1.2.6. HEAD : ヘッダー情報の取得
HEADメソッドは、GETメソッドと同様にサーバーから情報を取得しますが、レスポンスボディは返されません。リソースのヘッダー情報(メタデータ)を取得するために使用されます。
主にリソースの存在確認や、データの変更日時などを確認するために使用されます。
1.2.7. OPTIONS : サポートされているメソッドの確認
OPTIONSメソッドは、指定されたリソースがサポートしているHTTPメソッドの一覧を取得するために使用されます。
このメソッドは、クライアントがリソースに対してどの操作が可能かを知るために利用されます。
主にCORS(クロスオリジンリソースシェアリング)のPreflighted Requests(プリフライトリクエスト)として使用されます。
※Preflighted Requests:WebサーバーがCORS要求を受け付けるか、実際のリクエストの送信前に確かめること
1.2.8. TRACE : リクエストのループバックテスト
TRACEメソッドは、リクエストがサーバーに到達する際の経路を確認するために使用されます。サーバーは、リクエストをそのままレスポンスとして返します。
主に診断やデバッグの目的で使用されますが、セキュリティ上の理由からほとんど使用されません。
1.2.9. CONNECT : プロキシサーバーとのトンネリング
CONNECTメソッドは、サーバーとのトンネリング接続を確立するために使用されます。
主にSSL/TLSでの安全な通信を確立するために使用され、HTTPS通信のプロキシ設定時に利用されます。クライアントはこのメソッドを使用してサーバーとの安全な接続を確立します。
※トンネリング:ネットワーク通信においてプロキシサーバーを介して暗号化された安全な通信を確立する技術
まとめ
本記事では、Web APIの基本概念とHTTPメソッドについて紹介いたしました。
Web API理解のために少しでもお役に立てれば幸いです。
次回記事からは、具体例を元にWeb APIの設計方法や、設計における注意点をご紹介いたします。