* 프로그래머스, 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 5기 강의 수강 내용을 정리하는 포스팅.

* 원활한 내용 이해를 위해 수업에서 제시된 자료 이외에, 개인적으로 조사한 자료 등을 덧붙이고 있음.

1. API

API? REST? RESTful?

• API? REST? RESTful? 이전 포스팅 참조.

• API. Application Programming Interface

• 서버와 클라이언트 간의 데이터 통신을 위한 규약이나 기능.
• 백엔드 서버로부터 데이터를 가져오거나 데이터를 보낼 때 사용하는 인터페이스.
• 간단하게 표현하자면 데이터를 가져오거나 조작하는 데 필요한 방법 혹은 도구를 통칭하는 단어.

HTTP - RESTful - API

• HTTP에 대한 상세 내용은 이전 포스팅 참조.

• HTTP는 네트워크에서 데이터를 주고받는 통신 규약.

• REST은 HTTP를 가장 잘 효율적으로 이용할 수 있는 방법을 제시하는 규칙.

• API는 데이터를 가져오거나 조작하는 데 필요한 방법 혹은 도구.

• RESTful API는 REST 규칙을 준수하여 만든 API.
  - 한마디로, 웹 개발에서 프론트엔드 <-> 백엔드 사이에서 표준 규칙을 지키는 데이터를 주고받는 방법 내지 도구.
  - 기본 중의 기본.
  - 다만 API 설계 원칙에는 REST 이외에도 GraphQL도 존재하긴 한다. 내용 참고 AWS - GraphQL과 REST의 차이점은 무엇인가요?

2. HTTP의 기본 구조

요청 (Request) 데이터

• 요청 메서드 (Request Method): 서버에서 수행할 작업의 종류를 나타내는 정보.
  - GET, POST, PUT, DELETE, PATCH 등..

• URL (Uniform Resource Locator): 요청하는 리소스의 경로. 서버가 어느 리소스에 접근할지 결정한다.

• 헤더 (Headers): 요청에 대한 메타데이터를 포함, 여러 정보가 담길 수 있다.
  - Content-Type: 요청의 본문 데이터 형식을 나타냄 (예: application/json, text/html).
  - Authorization: 인증 토큰이나 자격 증명을 담아 보안 처리를 위한 정보 제공.
  - User-Agent: 클라이언트 정보를 담아 서버가 요청을 분석하고 처리할 수 있도록 함.

• 본문 (Body): 주로 POST나 PUT 메서드에서 사용, 서버에 전달할 데이터가 포함
  - 사용자 입력 데이터, 파일 업로드 내용 등..
  - GET 메서드에서는 사용하지 않는다. 이건 서버에서 데이터를 '조회'하는 용도이기 때문.
  - 원래는 GET에서 아예 Body 사용을 금지하다가, 근래에는 사용을 아예 막아두지는 않는 방향으로 바뀌긴 했다.
  - 그런데 HTTP 규약상 GET에서는 여전히 Body 사용을 권장하지 않고, 대부분의 브라우저나 서버에서는 GET에서 Body를 사용하는 것을 지원하지 않기 때문에 GET 메서드에서는 Body가 없다고 생각하는 것이 좋다.

• 쿼리 파라미터 (Query Parameters): URL에 추가로 붙어 리소스에 전달되는 값, 선택적 데이터를 제공.
  - ?page=2&limit=10
  - 요청 URL 등지에서 ? 문자로 구분되는 데이터. URL을 이용해서 서버로 특정 값을 전달하는 방법.
  - 보안에 민감하지 않는, 검색 키워드 등의 '가벼운' 데이터를 이동시키는데 대단히 유용하다.
  - GET 메서드는 Body를 사용할 수 없다.
  - 그런데 조회해올 데이터를 특정하기 위해 클라이언트에서 서버에 무언가 값을 보내야하는 경우가 있다.
  - 그럴 때 사용하는 것이 바로 쿼리 파라미터.

• 쿠키 (Cookies): (선택 요소) 상태를 유지하기 위해 클라이언트가 제공하는 데이터, 세션 관리나 인증에 사용.
  - 클라이언트 / 서버 양쪽에서 모두 쿠키를 생성해서 전송할 수 있다.
  - 보안 문제로 일정 시간마다 쿠키를 새로 생성하는 등의 상황이 벌어지기 때문.
  - 꼭 회원 기능에서만 사용하는건 아니고, 특정 사용자를 '구분'하는 모든 상황에서 다 사용된다.
  - 장바구니 기능, 다크 모드 등의 특정 사용자의 '맞춤 설정' 기능 등..

응답 (Response) 데이터

• 상태 코드 (Status Code): 요청이 성공했는지, 실패했는지, 또는 다른 처리가 필요한지를 나타내는 정보.
  - 200 OK, 404 Not Found, 500 Internal Server Error 등..

• 헤더 (Headers): 응답에 대한 메타데이터를 담고, 클라이언트가 응답을 어떻게 처리할지에 대한 정보를 제공.
  - Content-Type: 응답의 데이터 형식 (예: application/json, text/html)
  - Set-Cookie: 클라이언트에 쿠키를 저장하도록 지시
  - Cache-Control: 클라이언트가 응답을 캐시로 저장할 수 있는 조건 명시

• 본문 (Body): 클라이언트가 요청한 데이터가 포함.
  - HTML 문서, JSON 데이터, 이미지 파일 등..

• 쿠키 (Cookies): (선택 요소) 상태를 유지하기 위해 서버에서 제공하는 데이터, 세션 관리나 인증에 사용.

3. API 요청 처리 예시

• 프론트엔드 <-> 백엔드 <-> 데이터베이스 사이의 상호작용 예시는 이전 포스팅 참조.

// 회원가입 함수
export const checkEmailRequest = async (
    email: string
): Promise<EmailCheckResponse> => {
    const response = await fetch(
        `${import.meta.env.VITE_API_URL}/auth/check-email`, // 환경 변수를 사용하여 API URL 설정
        {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
            },
            body: JSON.stringify({ email }),
        }
    );

    if (!response.ok) {
        const errorData = await response.json();
        throw new Error(errorData.message || '이메일 확인에 실패했습니다.');
    }

    return response.json();
};

• 가장 먼저 수행해야할 것은, '어느 요청을 어떤 URL을 통해 받을 것인가?'를 정하는 것.
  - REST 규약에서 규정하는 방법을 준수하여 URL 구조를 설계하면 된다.

${import.meta.env.VITE_API_URL}/auth/check-email
${import.meta.env.VITE_API_URL}/auth/verify-email
${import.meta.env.VITE_API_URL}/auth/verify-code
${import.meta.env.VITE_API_URL}/auth/password-reset/request
${import.meta.env.VITE_API_URL}/user/get-userinfo
${import.meta.env.VITE_API_URL}/user/update-userinfo

• URL 구조 예시. 코드 출처는 내 가상의 향수 쇼핑몰 개인 프로젝트.

• 인증 관련 기능이 여럿이라면 'auth'으로 묶고, 그 하위 기능들을 '/'으로 구분하였다.