백엔드 개발자를 위한 HTTP 기본 지식

1. RESTful API의 개념 및 설계 원칙

RESTful API는 클라이언트와 서버 간의 역할을 명확히 분리하여 각 구성 요소가 독립적으로 발전할 수 있도록 설계된 아키텍처이다. 다음의 원칙들이 핵심이다.

• 클라이언트-서버 구조
  클라이언트와 서버가 서로의 구현에 영향을 받지 않고 독립적으로 변경될 수 있도록 역할을 분리한다.
• 무상태성(Stateless)
  서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리된다. 실제 개발 환경에서는 세션 등을 사용해 상태를 관리하기도 하지만, REST의 기본 원칙은 무상태를 유지하는 것이다.
• 캐시 처리 가능(Cacheable)
  응답 데이터는 캐시될 수 있어, 네트워크 부하를 줄이고 성능을 개선할 수 있다.
• 일관된 인터페이스(Uniform Interface)
  클라이언트와 서버 간의 상호작용을 단순화하고, 서로 다른 시스템 간에도 일관된 방식으로 통신할 수 있도록 한다.
• 계층화된 시스템(Layered System)
  리소스는 계층적으로 구성되어 클라이언트가 서버 내부 구조에 대해 알 필요 없이, 단순하게 상호작용할 수 있다.

---

2. HTTP 메서드의 차이점 및 용도

HTTP 메서드는 클라이언트가 서버에 요청할 때 사용되는 다양한 방식으로, 각 메서드는 특정 목적과 특징을 가진다.

GET

• 용도: 리소스 조회
• 특징:
  • 멱등성을 보장한다.
  • 응답은 캐시될 수 있다.
  • URL에 파라미터를 포함하여 데이터를 전달하며, 요청 본문은 사용하지 않는다.

POST

• 용도: 리소스 생성 또는 데이터 처리 요청
• 특징:
  • 멱등성을 보장하지 않는다.
  • 클라이언트가 요청을 보내면 서버가 해당 요청에 따라 새로운 리소스를 생성하거나, 기존 리소스에 변경을 가한다.
  • 응답은 캐시될 수 있으나, 요청 본문까지 고려해야 하므로 주의가 필요하다.

PUT

• 용도: 리소스 전체의 업데이트 또는 생성
• 특징:
  • 클라이언트가 업데이트할 리소스의 위치(URI)를 알고 있어야 한다.
  • 요청된 리소스를 완전히 덮어쓰며, 동일 요청을 여러 번 보내더라도 결과가 동일(멱등성 보장)하다.

PATCH

• 용도: 리소스의 일부 업데이트
• 특징:
  • 전체 리소스가 아닌 일부만 변경한다.
  • 멱등성을 보장하지 않아도 되며, 변경 범위가 작을 때 효율적이다.
  • 응답의 캐시 처리 시 요청 본문까지 고려해야 하므로 사용에 주의가 필요하다.

DELETE

• 용도: 리소스 삭제
• 특징:
  • 삭제 요청은 멱등성을 보장해야 한다.
  • 불명확한 삭제(예: "리스트의 마지막 항목 삭제")는 상태에 따라 결과가 달라질 수 있으므로 피해야 한다.

OPTIONS

• 용도: 서버가 지원하는 HTTP 메서드와 기타 옵션 정보를 확인하기 위한 요청
• 특징:
  • 주로 CORS의 Preflight 요청에 사용된다.
  • CORS 상황에서는 자격 증명(쿠키 등)이 포함되지 않으며, 이는 서버에서 요청을 거절할 수 있는 요인이 된다.

---

3. 세션과 쿠키의 차이점

세션과 쿠키는 모두 사용자 상태를 관리하기 위한 기술이지만, 관리 위치와 보안, 성능 측면에서 차이가 있다.

• 세션(Session)
  • 저장 위치: 서버 측
  • 장점: 보안성이 높으며, 중요한 정보를 서버에 안전하게 저장할 수 있다.
  • 단점: 서버 자원을 소모하므로, 많은 사용자가 동시에 접속할 경우 부담이 될 수 있다.
• 쿠키(Cookie)
  • 저장 위치: 클라이언트 측
  • 장점: 서버 부하를 줄이며, 간단한 상태 정보를 클라이언트에서 관리할 수 있다.
  • 단점: 데이터가 클라이언트에 저장되므로 보안에 취약하며, 노출될 위험이 있다.

---

4. JSESSIONID 사용 이유 및 취약점

JSESSIONID는 스프링 프레임워크에서 기본적으로 사용되는 세션 식별자이다.

• 사용 이유:
  • 프레임워크가 자동으로 생성 및 관리하기 때문에 개발자가 별도의 설정 없이 쉽게 사용할 수 있다.
• 취약점:
  • 쿠키 기반 특성: 쿠키에 저장되므로 쿠키 탈취나 XSS(교차 사이트 스크립팅) 공격에 취약하다.
• 보안 대책:
  • HTTPS 사용: 전송 데이터를 암호화하여 중간자 공격을 방지한다.
  • HttpOnly 옵션: 자바스크립트에서 쿠키에 접근하지 못하게 하여 XSS 공격 위험을 줄인다.
  • Secure 옵션: 보안 연결(HTTPS)을 통해서만 쿠키가 전송되도록 설정한다.

---

5. JWT(JSON Web Token)의 개념 및 활용 상황

JWT는 무상태 인증을 위한 토큰 기반의 인증 방식으로, 분산 시스템 환경에서 유용하게 사용된다.

• 개념:
  • 사용자의 인증 정보를 토큰에 포함하여 클라이언트와 서버 간에 안전하게 전달한다.
  • 토큰은 대칭키나 공개/개인 키를 사용하여 서명되고, 이를 통해 데이터의 무결성과 인증을 보장한다.
• 특징:
  • 무상태 인증: 서버는 별도의 상태 정보를 유지하지 않고, 클라이언트가 전송하는 토큰만으로 인증을 수행한다.
  • 정보 교환: 사용자 정보와 권한 등을 토큰 내에 포함할 수 있어, 서버 간의 인증 및 권한 부여에 유리하다.
  • 분산 환경: 여러 서버가 동일한 인증 정보를 공유할 수 있으므로, 마이크로서비스 아키텍처 등 분산 시스템에서 효과적이다.

---

6. CORS(Cross-Origin Resource Sharing)의 개념 및 필요성

CORS는 브라우저의 동일 출처 정책(SOP)으로 인해 발생하는 제약을 완화하여, 서로 다른 도메인 간의 안전한 리소스 공유를 가능하게 한다.

• 필요성:
  • 기본적으로 SOP는 악의적인 도메인에서 쿠키와 같은 민감한 정보를 전송하지 않도록 제한하지만, 실제 웹 애플리케이션에서는 의도적으로 다른 도메인 간의 리소스 접근이 필요하다.
  • 이 경우, CORS를 사용하여 서버가 허용하는 도메인을 명시적으로 설정함으로써 안전하게 리소스를 공유할 수 있다.
• 요청 방식:
  • 단순 요청(Simple Request):
    GET, POST, HEAD와 같이 단순한 헤더를 사용하는 요청은 별도의 사전 협상 없이 바로 처리된다.
  • 비단순 요청(Preflight Request):
    단순하지 않은 요청의 경우, 실제 요청 전에 OPTIONS 메서드를 사용하여 서버와 사전 협상을 거친 후에 본 요청을 수행한다.

비단순 요청의 CORS 처리 과정