【インターフェーステスト】HTTPインターフェース詳細検証リスト

概要

私たちが新しい HTTP API を構築、テスト、リリースしていたとき、私を含むほとんどの人は、構築しているすべてのコンポーネントの複雑さや微妙な違いについてまったく知りませんでした。

たとえ各コンポーネントを深く理解していても、頭の中に情報が多すぎる可能性があります。

一度にすべての情報を整理して体系的な API テスト戦略を立てることは不可能なので、次に、HTTP API テストのチェックリストを改良します。

主に以下の4つの観点からです。

HTTP
API 設計
コンテンツ
セキュリティ
クライアント
その他

HTTP

HTTP RFC (Request For Comments) 関連ドキュメントでは、HTTP 対話メカニズムとパラメータオプションが規定されているため、HTTP API のテストを適切に行うには、関連する RFC ドキュメントを理解する必要があります。

HTTP1.0: https://tools.ietf.org/html/rfc1945

HTTP1.1: https://tools.ietf.org/html/rfc7232

HTTP2: https://tools.ietf.org/html/rfc7540

HTTP API テストを実施するときは、次のプロトコルオプションまたはメカニズムを対象範囲として考慮する必要があります。

HTTP メソッドのセキュリティと冪等性。HTTP プロトコルは、さまざまなメソッドのセキュリティ機能と冪等機能を指定しており、サービスプロバイダーとしてのサーバーは、これらの機能をクライアントに提供する必要があります。安全性とは、メソッドを複数回呼び出しても副作用が発生しないことだけを意味しており、従来の意味での「セキュリティ」は含まれません。ここでの副作用とは、リソースの状態を指します。つまり、安全なメソッドはリソースの状態を変更しませんが、複数の呼び出しの戻り値は異なる可能性があります (他の安全でないメソッドによって変更される)。冪等性とは、メソッドの複数の呼び出しによって返される効果 (形式) に一貫性があり、クライアントがメソッドを繰り返し呼び出して同じ結果を期待できることを意味します。
HTTP メソッドのセキュリティと冪等性を次の表に示します。

認証、検証 HTTP 認証を正確に実装するには、API が 401 ステータスコードを提供する必要があります。
ステータスコード 201 Created。要求が正常に処理され、新しいリソースが作成されたことを示すには、「201 Created」識別応答コードを使用します。201 応答には、場所ヘッダーに新しいリソース URI を含めることができます。
ステータスコード 202 Accepted。リクエストが有効で処理されるが、まだ完了していないことを示すには、「202 Accepted」応答コードを使用します。通常、これはサーバー側のキューのバックグラウンド処理のコンテキストで使用されます。
ステータスコード 4xx と 5xx ステータスコードには重要な違いがあります。 4xx と 5xx ステータスコード: 4xx コードはクライアント側のエラーを示すために使用され、5xx コードはサーバー側のエラーを示します。
ステータスコード 410 Gone 応答コードは、その URL でリソースが使用されていたが、現在は使用されていないことをクライアントに通知する、十分に活用されていない応答コードです。これを API で使用して、削除済み、アーカイブ済み、または期限切れのアイテムを表すことができます。
ステータスコード 100-Continue - API クライアントが POST、PUT、パッチなどの大規模なエンティティリクエストを送信する準備をしている場合、HTTP ヘッダーで「Expect:100-Continue」を送信し、その後「100」になるまで待機することができます。エンティティエンティティを送信します。続行」応答。これにより、API サーバーは、エラー応答 (401 や 403 など) を返して帯域幅を無駄にする前に、リクエストの有効性を検証できます。この機能をサポートすることはあまり一般的ではありませんが、一部のシナリオでは API の応答性が向上し、帯域幅が削減されます。
接続キープアライブにより、複数の API リクエストに対して API サーバーへの接続を維持すると、パフォーマンスが大幅に向上します。正しく構成されていれば、ほぼすべての Web サーバーがキープアライブ接続をサポートします。
HTTP 圧縮。HTTP 圧縮は、HTTP API のネットワークパフォーマンスを向上させるために、応答本文 (受け入れエンコーディング: gzip) と要求本文 (コンテンツエンコーディング: gzip) の両方に使用できます。
HTTP キャッシュは、API 応答でキャッシュ制御ヘッダーを提供します。「cache-control:no-cache」は、キャッシュできない場合にプロキシとブラウザがこれを理解できるようにします。キャッシュ可能な場合は、キャッシュをプロキシで共有できるかどうか、リソースが「新しい」かどうかなど、さまざまな要素を考慮する必要があります。
キャッシュ検証。キャッシュ可能な API がある場合は、応答に最終変更ヘッダーまたは ETag ヘッダーを提供し、条件付きリクエストのため If-modified リクエストをサポートする必要があります。これにより、クライアントはキャッシュされたコピーがまだ有効であることを確認し、必要でない場合は完全なリソースのダウンロードを防ぐことができます。正しく実装されれば、条件付きリクエストが通常のリクエストよりも効率的になり、サーバー側の負荷が軽減されます。
条件付き変更、ETag ヘッダーを使用して、リソースの条件付き変更をサポートすることもできます。get で ETag ヘッダーを提供することで、後の POST、patch、または delete リクエストで if-match ヘッダーを提供し、最後に確認したのと同じ状態でリソースを更新しているか削除しているかを確認できます。
絶対リダイレクト、http/1.1 へのリダイレクト (例: ...201、301、302、303、307 応答コード) は、Location 応答ヘッダーに絶対 URI を含める必要があります。多くのクライアントはロケーションの相対 URI をサポートしていますが、API を多くのクライアントと広範な互換性を持たせたい場合は、リダイレクトで絶対 URI を使用する必要があります。
RESTful API のリンク応答ヘッダーでは、応答のコンテンツタイプが自然なリンク方法 (PDF や画像表現など) を提供していない場合でも、他のリソースへのリンクを提供する必要があることがよくあります。RFC5988 は、応答ヘッダーでリンクを提供する方法を指定しています。
正規 URL、複数の URL を持つリソースについては、RFC6596 で正規 URL リンクを提供する一貫した方法が定義されています。
チャンク転送エンコーディング。応答するコンテンツが大量にある場合は、チャンク転送エンコーディング: チャンクはクライアントに応答するための良い方法です。これにより、サーバーと仲介者 (特に HTTP 圧縮の実装) でのメモリ使用要件が軽減され、最初のバイト応答が高速になります。
チャンク転送エンコーディングでのエラー処理、チャンク転送エンコーディングを実装して実装する前に、リクエストで発生したエラーを処理する方法を理解してください。応答の処理が開始されると、HTTP ステータスコードは変更できません。多くの場合、コンテンツタイプ内でエラーを表す方法を定義する必要があります。
X-HTTP-Method-Override、一部の HTTP クライアントは GET と POST のみをサポートします。他の HTTP メソッドは POST 経由でトンネリングでき、実際の標準 x-HTTP-method-override ヘッダーを使用して「実際の」HTTP メソッドをログに記録します。
URL の長さ。API が GET パラメータとして複雑または任意のフィルタリングオプションをサポートしている場合は、クライアントとサーバーの両方で 2000 文字を超える URL で互換性の問題が発生する可能性があることに注意してください。

API設計

優れた API 設計原則を学び理解することは、API の詳細なテストと検証を実施して、API の使いやすさとセキュリティを向上させるのに役立ちます。

ステートレス性により、アプリケーションサーバーの状態を常に維持することで、簡単かつ手間をかけずに拡張および保守を行うことができます。
コンテンツネゴシエーション、リソースの複数の表現をサポートしたい場合は、コンテンツネゴシエーション (例: accept ヘッダー)、または異なる URL に異なる URL (例: format=json) を使用するか、コンテンツネゴシエーションリソースのリダイレクトを特定の URL に設定することができます。フォーマット。
URI テンプレート、URI テンプレートは、クライアントに URL 構成機能を提供したり、エンドユーザーに URL アクセスパターンを記録したりするために使用される、明確に定義されたメカニズムです。
意図を考慮した設計。API を通じて内部ビジネスオブジェクトを公開するだけではありません。意味的に意味があり、ユーザーが使用する例と一致するように API を設計します。
理論的には、優れた API を事前に設計していれば、API に非互換性を作成する必要はありません。私たちの中の実用主義者にとって、API URL (例: a/v1/path) にバージョン管理を入れることで、API を制御およびアップグレードするメカニズムが得られます。
認可は、認証を通じて、どの API にパブリックにアクセスできるか、またアクセスする前にどの API を認証する必要があるかを制御し、それによって API のアクセス権を制御および管理します。
一括操作: サーバーと対話するリクエストの数を減らすことができるのであれば、一括操作 API は非常に優れた設計です。
ページネーション、ページネーションには API で 2 つの主な目的があります: 1 つはクライアントに送信される不要なデータの量を減らし、アプリケーションサーバーでの不要な計算の量を減らすことです; もう 1 つはリソースのページネーション収集のためのさまざまなモードです。
Unicode、統一された文字エンコーディング
エラーログ: API エラーを記録するログメカニズムが存在することを確認し、ユーザー入力によって発生したエラーをアプリケーションエラーとは別に記録します。

コンテンツ

コンテンツタイプについて詳しく説明するには、本が 1 冊必要になります。ここでの主なポイントは、その重要性を指摘することであり、開発プロセスでは、Atom、Collection+JSON、JSON HAL、XHTML などの標準または実績のあるコンテンツ形式を可能な限り再利用する必要があります。
HATEOAS、アプリケーションステートエンジンとしてのハイパーメディアは REST 制約です。簡単に説明すると、これは、コンテンツがリンクやフォームを通じて次に何を行うかを顧客に伝える必要があることを意味します。
日付/時刻、API で日付/時刻値を指定する場合は、一貫性を保つためにタイムゾーン情報を含む形式を使用します。

安全性

SSL - API を HTTP および HTTPS で提供するか、それとも HTTPS のみを使用するかを検討します。HTTPS はますます人気のあるオプションです。
CSRF クロスサイトリクエストフォージェリ API が対話ユーザーが使用するものと同じ認証設定を受け入れる場合、CSRF 攻撃に対して脆弱になる可能性があります。したがって、CSRF 攻撃を防ぐメカニズムが必要です。
スロットリングにより、API ユーザーが非常に愚かな API クライアントを作成してシステムのパフォーマンスを低下させることができなくなります。API ユーザーが提供される API リクエストの制限を超えた場合は、retry-header を含む 503 レスポンスをユーザーに返します。
巧妙なサービス拒否、DDoS 攻撃の防止

クライアント

私たちが提供する API をユーザーが効果的に使用できるようにするには、ユーザーによる API の悪用を防ぐために、ユーザー向けのいくつかの基本ルールをカスタマイズする必要があります。
接続キープアライブ。一部の HTTP クライアントライブラリでは、永続的な接続を有効にするために追加の作業を行う必要があります。永続的な接続は、API のパフォーマンスに大きな影響を与える可能性があります。
認可前の 401、一部の HTTP クライアントライブラリのもう 1 つの奇妙な点は、認可ヘッダーを使用してリクエストを行う前に「401 Unauthorized」応答が必要になることが多いことです。これにより、特に高遅延が問題となるモバイルネットワークでは、API リクエストに多くの時間がかかる可能性があります。
Expect: 100- continue、少なくとも 1 つの API クライアントがデフォルトで「Expect:100 continue」を使用します。「100 continue」応答を受信しない場合、3 秒のタイムアウト後にリクエストを続行します。「100 continue」をサポートしていない場合は、クライアントでこの機能を無効にすることが最善です。無効にしないと、サービスのパフォーマンスが低下します。

他の

ドキュメント、API ドキュメントを書くのは確かに退屈ですが、多くの場合、手書きのドキュメントが最良のドキュメントになります。ユーザーができるだけ早く作業を開始できるように、実行可能なコードまたはcurlコマンドラインを必ず含めてください。
顧客とともに設計します。API を設計するだけでなく、可能な限りユーザーとコミュニケーションを取り、対話します。
FeedBack により、API ユーザーは API に関するフィードバックを提供できるようになります。これは、サポートチャネルを通じて行われる場合もあれば、ホストされたフォーラムやメーリングリストを通じて行われる場合もあります。ユーザーを摩擦から守るようにしてください。
自動テスト、API は自動テストを構築するために実行できる最も簡単なものである必要があります。結局のところ、それは自動化のために構築されました。ぜひご利用ください！

7 日間で 30 の実践的なインターフェイス自動テストプロジェクトを実践した後、28,000 人がバイトテストのポジションに加わりました。[自動テスト/インターフェーステスト/ソフトウェアテスト/パフォーマンステスト/Jmeter]

最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。

この情報は、[ソフトウェアテスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテストエンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。