メインコンテンツまでスキップ

1. Introduction (はじめに)

1. Introduction (はじめに)​

Web ブラウジング以外のアプリケーションは, HTTP [HTTP] を基盤として使用することがよくあります。これは "HTTP ベースの API", "REST API", または単に "HTTP API" を作成すると呼ばれることがあります。これは次のようなさまざまな理由で行われます:

  • 実装者, 仕様作成者, 管理者, 開発者, およびユーザーによる親しみやすさ;

  • さまざまなクライアント, サーバー, およびプロキシ実装の可用性;

  • 使いやすさ;

  • Web ブラウザの可用性;

  • 認証や暗号化などの既存のメカニズムの再利用;

  • ターゲット展開環境における HTTP サーバーとクライアントの存在; および

  • ファイアウォールを通過する能力。

これらのプロトコルは多くの場合アドホックで, 1 つまたは少数のサーバーによる展開と限られた一連のクライアントによる消費のみを意図しています。その結果, これらの条件を優先する HTTP ベースの API の定義を中心に, 実践とツールの集合が生まれました。

しかし, このようなアプリケーションが複数の独立した実装を持ち, 複数の非協調サーバーに展開され, 多様なクライアントによって消費される場合 (これは標準化活動によって定義された HTTP API でよくあるケース), 限定的な展開を意図したツールと実践は不適切になる可能性があります。

このミスマッチは主に, API のクライアントとサーバーが異なるペースで実装および進化し, 異なる機能とバージョンの展開が共存する必要があるためです。その結果, このような展開を意図した HTTP ベースの API の設計者は, サービスの拡張性をどのように処理するか, および異なる展開要件をどのように調整するかをより慎重に検討する必要があります。

より一般的には, HTTP を使用するアプリケーションプロトコルは次のような多くの設計決定に直面します:

  • 新しい URI スキームを定義すべきか? 新しいポートを使用すべきか?

  • 標準の HTTP メソッドとステータスコードを使用すべきか, それとも新しいものを定義すべきか?

  • HTTP の使用から最大の価値をどのように引き出すことができるか?

  • HTTP の他の用途 -- 特に Web ブラウジング -- とどのように共存するか?

  • 相互運用性の問題と "プロトコルの行き止まり" をどのように回避するか?

セクション 2 は本文書が適用される場合を定義し, セクション 3 は保持することが重要な HTTP の特性を調査し, セクション 4 には HTTP を使用するアプリケーションの仕様のベストプラクティスが含まれています。

本文書は主に, インターネット上に展開するために HTTP を使用してアプリケーションプロトコルを定義する IETF の取り組みを導くために書かれていますが, 他の状況にも適用可能です。ここでの要件は必ずしも汎用 HTTP 拡張の開発には適用されないことに注意してください。

本文書は [RFC3205] を廃止し, その間の HTTP に関する経験と発展を反映しています。

に最終更新