HTTP、HTTPS、および API

TCP が信頼性のある接続を確立すると、2 台のマシンは安全にバイトをやり取りできます。しかし、バイトそのものには意味がありません。共有されたプロトコルがなければ、サーバーはそのバイト列がファイル要求なのか、フォーム送信なのか、あるいはまったく別のものなのかを判断できません。

HTTP (Hypertext Transfer Protocol) は、通信のための構造化された形式を定義します。クライアントは request（たとえば GET /index.html）を送り、サーバーはステータス情報とデータを含む response を返します。

HTTP は、リソースの要求方法、メタデータの含め方、レスポンスの形式を標準化します。これにより、ブラウザ、サーバー、プラットフォームをまたいで、Web 通信が予測可能で相互運用可能になります。

要するに、TCP は配信を保証し、HTTP は理解を保証します。

HTTPリクエストは request line から始まります。ここにはmethodとpathが含まれます。例えば:
GET /users/123 HTTP/1.1
これは、サーバーに対してどの操作が要求されているか、そしてどのresourceが対象かを示します。

method は意図を伝えます。

• GET はdataを取得します。
• POST は新しいdataを送信します。
• PUT は既存のdataを更新します。
• DELETE はdataを削除します。

headers は、content type（Content-Type）、authentication credentials（Authorization）、またはclientに関する情報（User-Agent）など、追加のcontextを提供します。

最後に、いくつかのrequestには body が含まれます。例えば、POST request には server に送信される JSON data が含まれることがあります。

これらの要素が組み合わさることで、server が正しく parse して interpret できる、予測可能な構造が作られます。

HTTPレスポンスは、次のような ステータスライン から始まります:
HTTP/1.1 200 OK

ステータスコード はリクエストの結果を伝えます。

• 200 は成功を意味します。
• 404 はリソースが見つからなかったことを意味します。
• 500 はサーバー側のエラーを示します。

次に ヘッダー が続き、レスポンスに関するメタデータを提供します。これには Content-Type（例: JSON や HTML）、Content-Length、キャッシュのルール、セキュリティポリシーなどが含まれる場合があります。

最後に、ボディ には要求された実際のデータが含まれます。たとえば、HTMLページ、JSONオブジェクト、ファイルなどです。

レスポンスの構造によって、クライアントは何が起きたのかと、どのデータが返されたのかの両方を理解できます。

HTTP は stateless protocol として設計されています。つまり、クライアントがリクエストを送信すると、サーバーはそれ以前のコンテキストを前提にせずに処理します。

たとえば、Webページを読み込んでからボタンをクリックした場合、2回目のリクエストには最初のリクエストの記憶は自動的には含まれません。サーバーが処理するために必要な情報は、各リクエストにすべて含まれている必要があります。

ステートレスであることはスケーリングを सरल化します。サーバーが保存された接続状態に依存しないため、リクエストはロードバランサーの背後にある複数のマシンへ分散できます。

ログインセッションやショッピングカートのように継続性が必要なアプリケーションでは、cookies、session identifiers、または authentication tokens を使って状態を明示的に実装します。

HTTPS は HTTP over TLS (Transport Layer Security) の略です。HTTP メッセージを平文で送る代わりに、送信前にデータを暗号化します。

HTTPS では、ヘッダーとボディを含む HTTP リクエストとレスポンスのすべてが暗号化されます。これにより、ネットワーク上の攻撃者がパスワードやトークンなどの機密情報を読み取ることを防げます。

また、HTTPS ではサーバーが有効な デジタル証明書 を提示する必要があります。ブラウザはこの証明書を信頼された認証局と照合して、サーバーの真正性を確認します。

さらに、TLS は通信中にデータが変更されていないことを保証するために、暗号学的な整合性チェックを適用します。

要するに、HTTPS は Web 通信の機密性、真正性、完全性を保護します。

クライアントが HTTPS サーバーに接続すると、TLS はまず HTTP データが送信される前に handshake を行います。

処理は Client Hello から始まります。クライアントは対応している暗号アルゴリズム（cipher suites）を提案し、後で鍵生成に使われるランダムデータを送信します。

サーバーは Server Hello で応答し、暗号化パラメータを選択します。また、公開鍵を含み、信頼された Certificate Authority によって署名された digital certificate も送信します。

クライアントは証明書を検証し、（Diffie-Hellman などの）key agreement プロセスを実行します。両者は、その秘密を直接送信することなく、同じ共有秘密をそれぞれ独立に導出します。

ハンドシェイクが完了すると、共通鍵暗号の鍵が確立され、その後の HTTP トラフィックはすべて暗号化されます。

デジタル証明書 は、認証局（CA） と呼ばれる信頼された第三者によって発行されます。CA は、証明書を要求した組織が実際にそのドメイン名を管理していることを確認します。

証明書には、ドメインに関する識別情報とともに、サーバーの 公開鍵 が含まれます。この公開鍵は、TLS ハンドシェイク中に暗号化された通信を確立するために使用されます。

ブラウザーが Web サイトに接続するとき、証明書がすでに信頼している CA によって署名されているかを確認します。ブラウザーには、信頼された認証局の組み込みリストが付属しています。

証明書が有効で、期限切れではなく、要求されたドメインと一致している場合、ブラウザーは安全な接続を続行します。そうでない場合は、警告を表示します。

したがって、HTTPS における信頼は次の連鎖に基づいています:
あなたは CA を信頼する → CA はサーバーを信頼する → あなたはサーバーを信頼する。

API（Application Programming Interface） は、ソフトウェアコンポーネント同士がどのように連携するかを定めた正式な仕様です。利用可能な操作と、その操作へのアクセス方法を定義します。

Webシステムでは、APIは通常HTTPを使用します。クライアントは、GETやPOSTのような定義されたメソッドを使って、特定のエンドポイント（たとえば /users/123）にリクエストを送信します。

APIは、期待されるリクエスト形式（たとえば、リクエストボディ内のJSON）と、サーバーから返されるレスポンス形式の構造も定義します。

APIがなければ、システムは文書化されていない慣習や、強く結合した統合に依存することになります。APIは明確な境界を作り、独立した開発、スケーラビリティ、サービス間の相互運用性を可能にします。

REST（Representational State Transfer）は、API を アクション ではなく リソース を中心に整理します。リソースは /users や /orders/123 のような URL で表されます。

URL に動詞を埋め込む代わりに、REST では HTTP メソッド を使って操作を定義します。

• GET はデータを取得します。
• POST は新しいデータを作成します。
• PUT は既存のデータを更新します。
• DELETE はデータを削除します。

REST API は ステートレス です。つまり、各リクエストには必要な情報がすべて含まれています。サーバーは現在のリクエストを処理するために、以前のリクエストに依存しません。

多くの REST API は JSON 形式 でデータをやり取りします。JSON は軽量で、人間にも読みやすく、機械でも簡単に解析できます。

この構造により、REST API は一貫性があり、スケーラブルで、分散システム全体で理解しやすくなります。

404 見つかりません エラーは、サーバーには到達できているものの、要求されたルートまたはリソースが存在しないことを意味します。これは通常、アプリケーションレベルのルーティングの問題です。

500 内部サーバーエラー は、リクエストはサーバーに届いたものの、実行中に何かが失敗したことを示します。たとえば、クラッシュ、未処理の例外、データベース障害などです。

接続拒否エラーは、スタックのより前の段階で発生します。クライアントは TCP 接続を確立できず、これは多くの場合、サーバーが停止しているか、対象ポートでプロセスが待ち受けていないことが原因です。

SSL 証明書エラーは、証明書が無効、期限切れ、またはドメインと一致しない場合に TLS ハンドシェイク中に発生します。ブラウザーはユーザーを保護するために接続をブロックします。

混合コンテンツ警告は、HTTPS ページが HTTP リソースを読み込もうとしたときに表示されます。これは HTTPS のセキュリティ保証を損なうため、最新のブラウザーでは警告されます。

障害がどこで発生しているか — アプリケーション、トランスポート、または TLS — を理解することは、効果的なデバッグにとって重要です。