サーバーのレスポンスとデータ型

サーバーから送られてくるResponseは、Requestとほぼ同じ方式で動作する。明らかな理由により、リクエストパラメータを持ちませんが、 Headers と Body はレスポンスに含まれます (ただし、これらは空であるかもしれません)。

重要な違いは、レスポンスのステータスです。

ステータスコード

ステータスコードです。サーバーレスポンスの最初の行に入ります。ステータスは3桁の数字（コードそのもの）で、その後にそれを説明するフレーズが続きます。

ステータスコードによって、リクエストの結果を知り、次にどのような行動をとるべきかを理解することができるのです。

ステータスコードは、5つのクラスに分類されています。コードの最初の桁が、特定のクラスに属するかどうかを決定します。それらを分解してみましょう。

1xx- 情報コード。リクエストの進行状況を報告します。実際の運用では、ほとんど使用されません。

2xx- 成功コード。すべてが正常に行われ、リクエストが成功したことを報告する。GETリクエストの応答として、私たちは通常200(OK)コードを受け取ることを期待します。PUTリクエストに成功すると、201 (Created) コードが送信されます。

3xx- リダイレクト。リクエストが別のアドレスに送信される必要があることを示します。例として、コード301（Moved Permanently）があり、必要なデータが新しいアドレスにあることを示します（新しいアドレス自体はLocationヘッダで渡されます）。

4xx-クライアントエラーコード。最も有名なのは404（Not Found）で、指定されたアドレスに必要なデータが存在しないことを報告する。その他の一般的なケース。400（Bad Request、リクエストの構文エラー）、401（Unauthorized、アクセスに認証が必要）、403（Forbidden、アクセスが拒否された）。

5xx- サーバーエラーコード。サーバー側で発生したエラーを報告します。例として500 (Internal Server Error、既知のコードに帰着できない不可解なエラー)、503 (Service Unavailable、サーバーが技術的な理由で一時的にリクエストを処理できない)

データ型

ここまでで、REST APIとHTTPリクエスト、レスポンスの構造を理解するための基本的な情報を扱ったと考えてよいでしょう。あとは1点だけ、データ型について明らかにしておきます。AppMasterでAPIリクエストを作成しようとした場合、すべてのデータ（パラメータ、ヘッダ、ボディ）が名前だけでなくデータ型も要求されることに気づいたと思います。

通常、人間にとってデータをどのように扱うかは、特定のコンテキストがあるため、非常に明白である。例えば、2 + 2 = 4と知っているとしよう。これらは数字であり、足し算の結果は別の数字になると推測される。

しかし、それは数字ではなく、テキストデータかもしれない。そうすると、足し算の結果は文字列の連結となり、2＋2が「22」になる可能性がある。ここでは、コンピュータが何も考えなくてもいいように、データ型が正確に示されているのだ。そして同時に、他の課題も解決している。例えば、電話番号の入力欄にメールアドレスを登録することはできませんが、間違ったデータを入力しないようにするためです。

データ型には多くの種類がありますが、ここでは最も基本的なものを取り上げ、残りのデータ型については、このコースの次のモジュールで詳しく説明します。

文字列- 文字列データ型、特別な書式のないプレーンテキスト。

Integer- 整数データ型。カウンタや分数を必要としない計算に使用される。

Float- 浮動小数点数。精度を上げる必要があり、整数値では十分でない場合に使用されます。

ここで論理的な疑問が生じるかもしれません。なぜ常にFloatを使わないのか，それならなぜIntegerが必要なのか，ということです．しかし、精度を上げるにはより多くのリソースが必要です。小さな計算では全く気にならないかもしれませんが、大量のデータの場合、合理的なデータ型を使用することで、計算能力やディスクスペースに対する要求を大幅に削減することができます。

Boolean- ブール型データ型。最も単純なデータ型。2つの値のいずれかを取り、TrueまたはFalseと表記される。1（真）、0（偽）という形で指定されることが多いようです。