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

1. 고객이 요청합니다

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

여기서는 어떻게 되나요?

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

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

2. DNS 조회: 서버 찾기

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

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

3. 연결 설정

이제 클라이언트는 서버가 어디에 있는지 알았으므로 연결을 설정해야 합니다.

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

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

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

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

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

서버측 처리:

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

5. 대응 준비

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

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

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

6. 응답 보내기

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

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

7. 클라이언트가 응답을 수신하고 처리합니다.

클라이언트가 응답을 받으면 데이터를 처리하고 UI를 업데이트할 수 있습니다.

UI 업데이트: 날씨 애플리케이션에서 클라이언트는 응답에서 온도 데이터를 가져와 디스플레이를 업데이트하여 현재 날씨를 표시합니다.

오류 처리: 문제가 발생한 경우(예: 서버가 404 또는 500 상태 코드를 반환한 경우) 클라이언트가 오류 메시지를 표시하거나 요청을 다시 시도할 수 있습니다.

8. 연결 종료

데이터 교환이 완료되면 클라이언트와 서버 간의 연결이 종료됩니다.

TCP 연결 종료: 핸드셰이크와 유사하게 4단계 프로세스를 사용하여 연결이 종료됩니다.

1. FIN: 클라이언트가 완료(FIN) 요청을 보냅니다.
2. ACK: 서버가 FIN 요청을 승인합니다.
3. FIN: 서버가 자체 FIN 요청을 보냅니다.
4. ACK: 클라이언트가 서버의 FIN 요청을 확인합니다.

이 순서대로 종료하면 양측 모두 데이터 전송이 완료됩니다.

문제 해결 및 일반적인 문제

API 요청-응답 프로세스는 간단해 보이지만 다음과 같은 몇 가지 일반적인 문제가 발생할 수 있습니다.

• 네트워크 오류: 연결 시간 초과, 패킷 손실 또는 기타 네트워크 관련 문제로 인해 요청이 서버에 도달하지 못하거나 응답이 클라이언트에 도달하지 못할 수 있습니다.
• 인증/승인 실패: API 키, 토큰이 잘못되거나 만료되었거나 권한이 충분하지 않으면 인증 또는 승인 오류가 발생할 수 있습니다.
• 서버 측 오류: 서버는 데이터베이스 오류, 리소스 가용성 또는 서버 측 로직의 버그와 같은 문제에 직면하여 5xx 상태 코드가 발생할 수 있습니다.
• 클라이언트 측 오류: 클라이언트가 잘못된 매개변수를 제공하거나 존재하지 않는 리소스에 액세스하려고 시도하는 등 잘못된 요청을 수행하여 4xx 상태 코드가 발생할 수 있습니다.

이러한 문제를 해결하려면 네트워크 스니퍼, 브라우저 개발자 도구, 서버 측 로그와 같은 도구를 사용하여 문제의 근본 원인을 조사하고 이를 해결하기 위한 적절한 조치를 취할 수 있습니다.

결론

API가 내부적으로 어떻게 작동하는지 이해하면 간단한 HTTP 요청에도 관련된 복잡성을 이해하는 데 도움이 됩니다. DNS 조회부터 TCP 핸드셰이크, 서버측 처리, 클라이언트측 처리에 이르기까지 API 엔드포인트에 도달할 때마다 많은 일이 발생합니다.

개발자로서 이러한 개념을 확실히 이해하면 더 나은 코더가 될 뿐만 아니라 문제를 더 효과적으로 디버그하는 데에도 도움이 됩니다. 따라서 다음에 API로 작업할 때는 데이터가 이동하는 과정과 이를 가능하게 하는 복잡한 프로세스를 기억하세요.