テストとトラブルシューティングに不可欠な CURL API コマンド

アプリケーション プログラミング インターフェース (API) は、マイクロサービスまたはコンテナー ベースのアーキテクチャに不可欠な要素の 1 つにすぎません。 また、さまざまなサービスが相互に通信する方法を探している場合は、cURL API コマンドが驚くべき効果を発揮します。

このチュートリアルでは、cURL API の基本と、それをテストとトラブルシューティングに使用する方法のいくつかの実用的な例を学びます。

読み進めて、リクエストを安全に REST API に送信してみましょう!

前提条件

このチュートリアルは実践的なデモンストレーションです。 フォローしたい場合は、次のものが揃っていることを確認してください。

• Linux マシン – このチュートリアルでは Ubuntu 20.04 LTS を使用しますが、コマンドは Linux のどのフレーバーでも動作するはずです。

関連している：Ubuntu 20.04 のインストール方法 [Step-by-Step]

• カール Linux マシンにインストールされています。

関連している：Curl と PowerShell の比較: ユース ケースの比較

• テストする REST API – このチュートリアルでは、 {JSON} プレースホルダー、偽のオンライン REST API。 この偽の API を使用すると、実際の API を台無しにすることなく、さまざまな cURL コマンドをテストできます。

関連している：PowerShell JSON の例を使用した REST API のラングリング (4 つのデモ!)

cURL API コマンド (HTTP GET リクエスト) によるデータの取得

API のテストは、API が期待どおりに機能することを確認するために不可欠です。 API テストの最も一般的なタイプの 1 つは、HTTP GET 要求です。 サーバーから特定のデータを取得するには、HTTP GET 要求を使用します。

GET リクエストを行うには、接続先のサーバーの URL を指定する必要があります。 GET はデフォルトのリクエスト タイプであるため、GET を明示的に指定する必要はありません。

1.実行します カール 以下のコマンドで GET リクエストを行い、すべての投稿を JSON 形式で返します。

curl https://jsonplaceholder.typicode.com/posts

以下に示すように、userId、タイトルなどを含む JSON オブジェクトの長いリストが出力に表示されます。

出力には大量の投稿が含まれていることに注意してください (リストは続きます)。それを見るだけで、リストをスクロールするのが面倒であることがわかります。

特定の投稿または userId のみを取得する場合は、次の手順にジャンプしてください。

2. 次に、手順 1 と同じコマンドを実行します。 しかし今回は、?userId=1 クエリ パラメータを追加します。

クエリ パラメーターは、サーバーから取得するように指定したデータを抽出するように curl コマンドに指示します。 この場合、curl コマンドは特定の userId が 1 の各投稿を取得します。

curl https://jsonplaceholder.typicode.com/posts?userId=1

3. 最後に、以下の同じコマンドを再実行し、-i オプションを追加して、出力に応答ヘッダーを含めます。

curl -i https://jsonplaceholder.typicode.com/posts?userId=1

出力で、応答ヘッダーのステータス コードが 200 であることがわかります。これは、要求が成功したことを示しています。

使用する HTTP リクエスト メソッド (GET、POST、PATCH など) によって、ステータス コードは異なります。 読み進めると、各ステータス コードについて詳しく知ることができます。

HTTP POST リクエストでサーバーにデータを送信する

GET リクエストを送信してサーバーにデータを要求しましたが、逆の方法で代わりにデータを送信できますか? はい！ POST リクエストを送信することで、サーバー上に新しいデータを作成します。

ただし、POST リクエストを送信するときは注意が必要です。 なんで？ POST リクエストで送信したデータがサーバー上に存在する場合でも、POST リクエストはデータを上書きします。

以下のコマンドを実行して指定します (-X) POST 次のデータを使用して新しい投稿を作成するように要求します (-d) で区切られたキーと値のペアで、 & シンボル：

• あ userId の 10.
• のタイトル Hello World.
• の体 This is the body.

curl -X POST -i -d "userId=10&title=Hello World&body=This is the body." <https://jsonplaceholder.typicode.com/posts>

今回は、 201 以下に示すように、出力のステータス コード。 REST API では、201 ステータス コードは、要求が満たされ、新しいリソース/データが作成されたことを示します。

HTTP PUT リクエストの送信によるリソースの更新

ここまでで、GET および POST 要求を送信してデータを取得し、サーバーに追加する方法を学習しました。 しかし、代わりにサーバー上の既存のリソースを更新する予定がある場合はどうなるでしょうか? その場合、PUT リクエストの送信が有効になります。

以下のコマンドを実行して、PUT リクエストを指定 (-X) し、userId=1 のポスト ID 1 でデータを更新 (-d) します。

更新するリソース/データがサーバーに存在しない場合、PUT リクエストは、代わりに提供されたデータを使用して新しいリソースを作成します。

curl -X PUT -i -d "userId=1&title=Hello World&body=This is the body." <https://jsonplaceholder.typicode.com/posts/1>

以下では、 200 リクエストが成功したことを示すステータス コード。 サーバーは理解した PUT データをリクエストして更新しました。

次に、以下のコマンドを実行して同じデータを更新してみてください。ただし、今回は投稿 ID 番号を指定しません。

curl -X PUT -i -d "userId=5&title=Hello World&body=Post body." [<https://jsonplaceholder.typicode.com>](<https://jsonplaceholder.typicode.com/>)

The 404 以下の出力のステータス コードは、更新しようとしているリソースが指定されたサーバーに存在しないことを示しています。 この例では、404 ステータス コードの原因に注意する必要があります。

で投稿 ID を指定しなかったため、このステータス コードが表示されます。 curl 指図。 ただし、URL が間違っていると、このステータス コードが返されることもあります。

HTTP DELETE リクエストの送信によるリソースの削除

サーバーからリソースを削除する必要があるのはなぜですか? 多くの理由が考えられます。 たとえば、特定のリソースを使用しなくなった場合、そのリソースをサーバーから削除してスペースを節約することができます。

以下のコマンドを実行して (-X) を指定し、DELETE リクエストを送信して ID 2 の投稿を削除します。

curl -i -X DELETE [<https://jsonplaceholder.typicode.com/posts/2>](<https://jsonplaceholder.typicode.com/posts/2>)

RESTful 認証による API の保護

REST API に対してさまざまな要求を行う方法がわかったので、REST API で認証を使用する方法を学びましょう。 とにかくセキュリティは常に最優先事項です。

REST API で認証しないと、API の URL を知っている人なら誰でもリクエストを作成し、API からデータを取得できますが、これは望ましくありません。

REST API で認証するには 2 つの方法があります。 以下の 2 つの方法のいずれかを実装して、許可されたユーザーのみが API にアクセスできるようにする必要があります。

• 基本認証 – REST API で認証する最も簡単な方法。 この方法では、API に対して行うすべてのリクエストでユーザー名とパスワードを送信する必要があります。 基本認証を使用することの欠点は、すべてのリクエストでユーザー名とパスワードがプレーン テキストで送信されることです。リスクが高すぎます。
• トークンベースの認証 – この方法は、REST API で認証する方が安全です。 この方法では、まず API で認証を行い、トークンを取得する必要があります。 トークンは、API に対して行うすべての要求と共に送信されます。 基本認証とは対照的に、トークンベース認証を使用する利点は、すべてのリクエストでユーザー名とパスワードが送信されないため、より安全になることです。

GitHub API を使用した基本認証方法に触れて、それらがどのように機能するかを理解できるようにします。

以下のコマンドを実行して、GitHub API への GET リクエストを作成する基本認証用の GitHub ユーザー名 (-u) を指定します。 your_username を実際の G​​itHub ユーザー名に置き換えます。

curl -i -u your_username [<https://api.github.com/users/octocat>](<https://api.github.com/users/octocat>)

コマンドを実行した後、プロンプトが表示されたら GitHub パスワードを入力します。

ユーザーの GitHub リポジトリのリストを取得します。 octocat 以下に示すように、GitHub API を介して。

結論

この記事では、REST API での動作をテストするための重要な cURL API コマンドについて学習しました。 さまざまな cURL API リクエストを送信して、それらの動作を確認し、それらがどのように機能するかを理解することに触れました。

現在、REST API はどこにでもあります。 それらは、Google、Facebook、Amazon、Twitter など、ほぼすべての主要企業で使用されています。 したがって、それらを使用したい場合は、このチュートリアルが最初のステップです。

これで、REST API の基本が身に付きました。 さて、REST API にリクエストを行うと実際に何が起こるかをよりよく理解するために、 さまざまな種類のステータス コード?