一般的なAPIエラーとその修正方法

Webサイトであれアプリケーションであれ、ソフトウェアを構築するときは、ソフトウェア開発サイクルに品質保証を含める必要があります。見逃した場合、エンドユーザーのエクスペリエンスを確実に損なうバグのあるインスタンスをリリースする可能性が高くなります。

利害関係者はこれが起こることを決して望んでいません。そのため、テストはリリースの成功を監視し、追加した機能に対する肯定的な応答を保証します。これには、実際の顧客がフローをチェックする前に、フローが期待どおりに機能していることを確認するための最も一般的なユースケースシナリオが含まれます。

カバレッジスイートに含めるテストを検討するときは、APIテストに注意してください。これは、最も重要で広く使用されているタイプの1つです。API（アプリケーションプログラミングインターフェイス）はすべてのアプリケーションに存在し、複数のソフトウェアシステム間の適切な通信を担当します。APIの主な機能には、送信できるデータリクエストと、これらのリクエストを処理するための条件を指定することが含まれます。 

たとえば、ユーザーがカートにアイテムを追加したい場合、APIリクエストをトリガーする対応するボタンを押し、応答を受信すると、カートが更新されます。このリクエストが失敗すると、「カートに追加」機能が機能しなくなります。

これがAPIの問題がビジネスに影響を与える可能性がある方法であり、誰もがAPIを適切にテストする必要があるもう1つの重要な要素を追加します。このテストを組み込むには、適切な自動化APIテストツールから始めて、エラーがすり抜けないようにする必要があります。

さまざまなAPIエラーが発生する可能性があります。ここでは、最も人気のある5つのエラーについて詳しく説明します。 

不正なHTTPメソッド

最も単純でありながら広く普及しているAPIエラーは、誤ったHTTPメソッドです。多くの場合、この問題はドキュメントのギャップが原因で発生します。例の1つは、データオプションを指定するGETリクエストを送信することですが、-XGETパラメーターについては言及しないでください。その結果、POSTリクエストに自動的に変換されます。また、APIツールを切り替えるときにHTTPメソッドの問題が発生する可能性があります。これは、テスト環境の作成と変更に1つのメソッドを使用するものと、これらのアクションに別々の方法を使用するものがあるためです。そのため、これらのニュアンスを注意深く確認し、独自のドキュメントを作成するための一貫したアプローチを採用することが重要です。 

間違ったプロトコルを使用する

もう1つの一般的なエラーは、https：//プロトコルとhttp：//プロトコルの間の不一致です。一部のAPIは、たとえばhttpなどのプロトコルの1つのみをサポートする場合があるため、このような場合にhttps：//を指定すると、誤ったリクエスト処理が発生します。両方がサポートされている場合でも、http：//を指定すると、https：//へのリダイレクトに問題が発生する可能性があります。このケースは、使用する予定のサードパーティAPIのプロバイダーが変更を加え、その通知を送信できない場合にも発生する可能性があります。したがって、これらの側面を時々再確認することをお勧めします。独自のAPIを作成するには、https：//プロトコルを使用することをお勧めします。これを可能にするには、SSL証明書をインストールする必要がありますホストに。少し前までは、SSL証明書は少しコストがかかるため、疑わしいかもしれませんが、LetsencryptやCloudflareなどの無料プロバイダーを使用すると、これまでになく簡単になります。

意味のあるエラーメッセージがない

「予期しないAPIエラーに直面したことがある場合」、あなたはこれがどれほど迷惑かもしれないか知っています。通常、エラーメッセージは、エラーの正確な理由または少なくともエラーを検索する場所を指摘する開発者のトラブルシューティングを容易にすることになっています。残念ながら、そのような情報のないエラーは、何時間もの無駄な時間をもたらし、エラーを解決するために必要な時間を増やし、その結果、受け取る負のフィードバックに大きなスパイクを引き起こす可能性があります。そのため、可能性の説明にもう少し時間を費やす方がよいでしょう。エラーと、それらのトラブルシューティングが必要な人のためにメッセージを有益なものにします。HTTPエラーコードは数十ありますが、すべてを使用する必要はありませんが、標準のエラーコード（200、400、500）を維持し、メッセージにヒントを含めることを検討してください。

認可トラブル

間違った認証は通常、ユーザー名またはパスワードが間違っていることを前提としているため、ここではすべてが明らかであるように見えるかもしれませんが、実際には、ヘッダーの「認証」と「認証」を混同してもエラーが発生します。これは、OAuth2プロトコルを使用する場合に特に有効です。また、構文は重要です。単純でありながらあまり目立たないことが混乱を招く可能性があるためです。ほとんどの場合、これらはベアラートークン、「Basic」プレフィックスのスペースであり、このプレフィックスを完全に追加するために欠落しており、「username：password」ペアのコロンが失われています。パスワードを必要としない一部のAPIでユーザー名を単独で使用する場合でも、このコロンを使用する必要があります。

Content-TypeヘッダーとAcceptヘッダーの指定に失敗しました

一部のAPIは、ヘッダーにContent-TypeまたはAcceptヘッダーが含まれていないが、許可されたデータ形式に対応しているリクエストに耐性があります。他の人はより慎重で、403PermissionDeniedエラーコードを提供することでリクエストを許可しません。この段階で、要求と応答で予想されるデータ型に関するクライアントとサーバー間の相互作用が確立されます。このヘッダーチェックは、セキュリティ違反や全体的なハッキングの試みのリスクを下げるために実装されています。そのため、使用中のトラブルを避けるために、これらのヘッダーを指定することをお勧めします。

要約

APIテストを、回帰、スモークテスト、そしてもちろん、開発スプリント中の単体テストを含む他のテストタイプと一緒に実行すると、ソフトウェアのリリースをより迅速に行うことができます。その背後にあるロジックは単純です。バグ、欠陥、またはビジネス要件との不整合に気付くのが早ければ早いほど、修正が容易になります。その結果、プロセスで予期しないバグが発生することなくソフトウェアとの対話を楽しむことができるエンドユーザーに一流のエクスペリエンスを提供し、ビジネスにより多くの利益をもたらします。