あなたのIPv4アドレス：
216.73.217.103
オペレーティングシステム：
位置情報：
United States Of America, Columbus
プロバイダー：
Amazon.com Inc.

Webサービスとは？

Webサービスとは、アプリケーション同士がネットワーク経由でデータを交換したり、機能を呼び出したりするためのインターフェースです。Webサイトが主に人が読んで使うために作られているのに対し、Webサービスはソフトウェアのクライアント向けに取り決め（コントラクト）を公開しています。1つの製品が両方を提供していることもあります。多くのサービスはHTTPとJSONを使っていますが、この言葉にはほかのプロトコルやデータ形式も含まれます。

リクエストとレスポンスの流れ

クライアントは、定められたエンドポイントに、メソッド、パラメーター、必要に応じて認証情報を付けてリクエストを送ります。サービスはリクエストを検証し、処理を行ってレスポンスを返します。HTTPのAPIでは、ステータスコードで大まかな結果を区別します。成功したのか、入力が不正などクライアント側に問題があるのか、サーバー側で失敗したのかがわかります。より詳しい情報は、通常レスポンスの本文に、ドキュメントで定められた形式で返されます。

明確な取り決めには、パス、メソッド、フィールド、型、認証、レート制限、エラー条件が記載されています。これがあるからこそ、クライアントを独立して開発できます。エンドポイントのアドレスが変わらなくても、フィールドやその解釈を変えると既存のアプリケーションが動かなくなることがあるため、バージョン管理が重要です。約束した範囲では後方互換性を保ち、廃止までの猶予期間を公表しましょう。

主なインターフェースのスタイル

RESTはアーキテクチャのスタイルであり、特定の通信形式を指すものではありません。RESTfulと呼ばれるHTTP APIでは、一般にリソースをURLで表し、読み取りにはGET、変更にはPOSTやPUTといったメソッドを使います。クライアントや中継サーバーがGETを繰り返したりキャッシュしたりすることがあるため、GETで永続的な状態変化を起こしてはいけません。SOAPは構造化されたXMLメッセージと形式的なサービス記述を使うもので、多くの企業システムで採用されています。

GraphQLでは、クライアントがスキーマを通じて必要なフィールドを指定して取得でき、多くの場合HTTP上で動作します。不要なデータ転送を減らせる反面、クエリのコスト、認可、キャッシュの面で複雑さが増します。Webhookは、通常のポーリングとは逆向きの仕組みです。イベントが発生すると、サービスの側から登録済みのエンドポイントを呼び出します。Webhookには、送信元の認証、再送の処理、重複配信への対策が必要です。どの方式にも、あらゆる場面で最適というものはありません。

セキュリティとプライバシー

転送中のデータを守るためにHTTPSを使い、サーバー証明書を検証しましょう。呼び出し元は適切な認証方式で認証し、操作ごと、オブジェクトごとに個別に認可を行います。有効なトークンが証明するのは、そのスコープで許可された範囲だけです。トークンがあるからといって、任意の入力が安全になるわけではありません。リクエストのサイズと型を検証し、エラーで非公開のデータを漏らさないようにし、不正利用に備えて制限を設けてください。

シークレットを公開URL、クライアント側のソースコード、ログに含めてはいけません。漏れた認証情報はローテーションし、スコープを絞り、本番用とテスト用の認証情報を分けましょう。コールバックURLを受け付けるAPIでは、内部ネットワークへのリクエストを防ぐために宛先を検証します。どの個人データを返すのかを文書化し、必要なものだけを保持してください。

信頼性とパフォーマンス

ネットワークには障害がつきものなので、クライアントにはタイムアウト、回数を制限したリトライ、部分的な失敗への明確な対処が必要です。読み取りは安全であれば再試行できますが、決済などの変更処理を再試行するには、重複を防ぐために冪等性を考慮した設計が欠かせません。大量の結果はページネーションで分割します。変化の少ない公開データならキャッシュで負荷を減らせますが、頻繁に変わるデータや非公開のレスポンスには慎重なキャッシュポリシーが必要です。

運用者は、実際のクライアントの経路で遅延、エラー率、可用性を測定すべきです。サーバーがHTTP 200を返していても、データが不完全だったり使えなかったりすることがあるため、期待される業務上の結果も監視しましょう。レート制限はサービスを守るものですが、予測しやすい形で伝える必要があります。利用者にとって重要なサービスであれば、障害時に備えてステータスページやサポート窓口を用意してください。

サービスを選ぶ・作るときは

まず利用者がやりたいことと、データの取り決めから考え、クライアントが実装でき、チームが保守できるインターフェースのスタイルを選びましょう。正常なレスポンス、不正な形式の入力、期限切れの認証情報、権限、ページネーション、タイムアウトをテストします。サンプルは常に最新の状態に保ち、具体的なエラーを示してください。外部のサービスを組み込むときは、利用制限、データポリシー、変更のお知らせを読んでおきましょう。便利なエンドポイントであっても、障害が起こりうる依存先であることに変わりはありません。