API가 내부적으로 작동하는 방식-JS 튜토리얼-php.cn

API(애플리케이션 프로그래밍 인터페이스)는 현대 소프트웨어 개발의 기본이며, 다양한 시스템이 서로 통신할 수 있도록 해줍니다. 하지만 API 엔드포인트에 도달하면 어떻게 될까요? 데이터가 클라이언트 애플리케이션에서 서버로, 그리고 그 반대로 어떻게 이동합니까? 이 문서에서는 시각적 자료와 추가 설명을 통해 API 요청 과정을 단계별로 분석하여 이러한 프로세스를 명확하게 설명합니다.

1. 클라이언트의 요청

날씨 데이터를 표시하는 웹 애플리케이션을 구축한다고 상상해 보세요. 사용자가 현재 날씨를 보기 위해 버튼을 클릭하면 애플리케이션은 https://api.weather.com/current와 같은 API 엔드포인트에 요청을 보냅니다.

여기서 무슨 일이 일어나는 걸까요?

HTTP 요청: 클라이언트(애플리케이션)는 메소드(예: GET, POST), 엔드포인트 URL 및 필요한 헤더(예: Authorization 또는 Content-Type)를 지정하여 HTTP 요청을 생성합니다.
페이로드: POST 요청인 경우 매개변수가 있는 JSON 객체(예: { "city": "New York" })와 같은 페이로드가 포함될 수 있습니다.

이 HTTP 요청은 인터넷을 통해 API를 호스팅하는 서버로 전송됩니다.

How APIs Work Under the Hood

2. DNS 조회: 서버 찾기

요청이 서버에 도달하기 전에 먼저 어디로 가야 할지 알아야 합니다. 이것이 바로 도메인 이름 시스템(DNS)이 들어오는 곳입니다.

DNS 조회: 브라우저 또는 클라이언트 애플리케이션은 도메인(예: api.weather.com)을 가져와 DNS 서버에 쿼리하여 해당 IP 주소를 찾습니다. 이 IP 주소는 인터넷상의 실제 서버 위치입니다.

How APIs Work Under the Hood

3. 연결 설정

클라이언트가 서버 위치를 알았으니 이제 연결을 설정해야 합니다.

TCP 핸드셰이크: 클라이언트와 서버는 TCP(전송 제어 프로토콜)를 사용하여 연결을 설정합니다. 여기에는 TCP 핸드셰이크로 알려진 3단계 프로세스가 포함됩니다.

SYN: 클라이언트가 서버에 동기화(SYN) 요청을 보냅니다.
SYN-ACK: 서버는 이 요청을 승인하고 SYN-ACK로 응답합니다.
ACK: 클라이언트가 서버의 응답을 확인하고 핸드셰이크를 완료합니다.

이 핸드셰이크가 완료되면 연결이 설정되고 데이터를 교환할 수 있습니다.

How APIs Work Under the Hood

4. 서버가 요청을 수신합니다

연결이 설정되면 HTTP 요청이 서버로 전송됩니다.

서버측 처리:

라우팅: 서버는 요청을 수신하고 엔드포인트(예: https://api.weather.com/current의 /current)를 기반으로 적절한 핸들러로 라우팅합니다. 여기에는 URL 패턴을 특정 컨트롤러 또는 기능과 일치시키는 것이 포함될 수 있습니다.
컨트롤러 로직: 서버의 컨트롤러가 요청을 처리합니다. 여기에는 데이터베이스를 쿼리하여 데이터를 검색하거나, 계산 또는 데이터 변환을 수행하거나, 추가 정보를 가져오기 위해 다른 내부 서비스를 호출하는 작업이 포함될 수 있습니다.
인증 및 승인: 엔드포인트에 인증이 필요한 경우 서버는 클라이언트의 자격 증명을 확인합니다. 예를 들어 요청에 API 키 또는 액세스 토큰이 포함된 경우 서버는 유효성을 확인하고 클라이언트가 요청된 리소스에 액세스하는 데 필요한 권한이 있는지 확인합니다.

5. 대응 준비

요청을 처리한 후 서버는 응답을 준비합니다.

응답 개체: 서버는 다음을 포함하는 HTTP 응답 개체를 생성합니다.

상태 코드: 요청 결과를 나타냅니다(예: 200 OK, 404 Not Found, 500 내부 서버 오류).
헤더: Content-Type(예: application/json) 또는 Set-Cookie와 같은 응답에 대한 메타데이터를 제공합니다.
본문: 클라이언트가 요청한 데이터가 포함되어 있으며 대개 JSON 형식입니다(예: { "온도": "72°F", "조건": "맑음" }).

6. 답변 보내기

서버는 설정된 연결을 통해 클라이언트에 HTTP 응답을 다시 보냅니다.

데이터 전송: 이 응답은 인터넷을 통해 다시 이동하며 잠재적으로 다양한 라우터와 게이트웨이를 통과합니다. 마침내 응답을 처리하는 클라이언트에 도달합니다.

How APIs Work Under the Hood

7. クライアントは応答を受信して処理します

クライアントは応答を受信すると、データを処理して UI を更新できます。

UI 更新: 天気予報アプリケーションでは、クライアントは応答から温度データを取得し、表示を更新して現在の天気を表示します。

エラー処理: 何か問題が発生した場合 (例: サーバーが 404 または 500 ステータスコードを返した)、クライアントはエラーメッセージを表示するか、リクエストを再試行することがあります。

8. 接続の終了

データ交換が完了すると、クライアントとサーバー間の接続が閉じられます。

TCP 接続の終了: ハンドシェイクと同様に、接続は 4 段階のプロセスを使用して終了されます。

FIN: クライアントは終了 (FIN) リクエストを送信します。
ACK: サーバーは FIN リクエストを確認します。
FIN: サーバーは独自の FIN リクエストを送信します。
ACK: クライアントはサーバーの FIN リクエストを確認します。

この秩序あるシャットダウンにより、双方がデータの送信を確実に完了します。

How APIs Work Under the Hood

トラブルシューティングと一般的な問題

API リクエストとレスポンスのプロセスは単純そうに見えますが、次のような一般的な問題がいくつか発生する可能性があります。

ネットワークエラー: 接続タイムアウト、パケット損失、またはその他のネットワーク関連の問題により、リクエストがサーバーに到達できなかったり、応答がクライアントに到達できなかったりすることがあります。
認証/認可の失敗: API キー、トークンが正しくないか、期限切れであるか、権限が不十分であると、認証または認可エラーが発生する可能性があります。
サーバー側エラー: サーバーでは、データベース障害、リソースの利用不能、サーバー側ロジックのバグなどの問題が発生し、5xx ステータスコードが発生する可能性があります。
クライアント側エラー: クライアントは、不正なパラメーターを指定したり、存在しないリソースにアクセスしようとしたりするなど、無効なリクエストを行って、4xx ステータスコードを引き起こす可能性があります。

これらの問題のトラブルシューティングを行うには、ネットワークスニファー、ブラウザ開発者ツール、サーバー側ログなどのツールを使用して、問題の根本原因を調査し、解決するための適切な措置を講じることができます。