TIL [20240617] - HTTP, REST

📖 오늘의 학습 키워드

HTTP, REST

🌐 HTTP

HTTP(Hypertext Transfer Protocol)는 웹 브라우저와 웹 서버 간에 데이터를 주고받기 위한
애플리케이션 레이어 프로토콜입니다. HTTP는 클라이언트-서버 모델을 기반으로 하며, 클라이언트가 
서버에 요청(request)을 보내면 서버는 그에 대한 응답(response)을 제공합니다.

🔄 HTTP의 통신 과정

1. 클라이언트가 URL을 입력하거나 링크를 클릭하여 서버에 요청을 보냅니다.
2. 서버는 요청을 받아 처리하고, 응답을 생성합니다.
3. 서버는 응답을 클라이언트에게 전송합니다.
4. 클라이언트는 응답을 받아 처리하고, 필요한 경우 추가 요청을 보냅니다.

🌐 HTTP 주요 특징

무상태(Stateless)

• HTTP는 각 요청-응답 쌍이 독립적으로 처리되며, 서버는 클라이언트의 이전 요청에 대한 정보를 유지하지않음
• 서버는 각 요청을 개별적으로 처리하고, 요청 간의 연결 상태를 유지하지 않음
• 이는 서버의 부하를 줄이고 확장성을 높일 수 있지만, 필요한 경우 쿠키나 세션을 사용하여 상태를 유지하는 방법도 있음

메서드(Method)

클라이언트가 웹서버에게 요청하는 목적 및 그 종류를 알리는 수단을 말한다.

• GET:
  • 지정된 리소스를 요청
  • URL(URI) 형식으로 서버 측에 리소스를 요청함
• HEAD:
  • GET요청과 유사하지만, 응답 본문을 받지 않고 헤더 정보만 요청
• POST:
  • 서버에 데이터를 제출하여 처리를 요청
  • 주로 폼 데이터를 전송하는 데 사용됨
• PUT:
  • 지정된 리소스를 업데이트
  • 리소스가 존재하지 않으면 새로 생성할 수도 있음
• DELETE:
  • 지정된 리소스를 삭제
  • 웹 서버측에 요청한 리소스를 삭제할 때 사용
  • 실제로 클라이언트에서 서버 자원을 삭제하도록 하진 않아서 비활성화로 구성
• CONNECT:
  • 클라이언트와 서버 사이의 중간 경유를 위함
  • 보통 Proxy를 통해 SSL 통신을 하고자할 때 사용
• OPTIONS:
  • 서버 측 제공 메서드에 대해 질의를 하기 위함
  • 웹 서버 측에서 지하고 있는 메서드가 무엇인지 알기 위해 사용한다
• TRACE:
  • Request 리소스가 수신되는 경로를 보기 위함
  • 웹 서버로부터 받은 내용을 확인하기 위해 loop-back 테스트를 할 때 사용
• PATCH:
  • 리소스(데이터)의 일부분만 갱신하기 위함
  • PUT과 유사하나 모든 데이터를 갱신하는 것이 아닌 리소스의 일부분만 수정할 때 쓰임

헤더(Header)

• HTTP 요청과 응답에는 헤더가 포함되어 있으며, 이는 요청 또는 응답에 대한 부가 정보를 제공함
• 헤더는 키-값 쌍 형태로 구성되며, 콜론(:)으로 구분됨
• 요청 헤더의 예시:User-Agent(클라이언트 정보), Accept(클라이언트가 처리 가능한 MIME타입), Cookie(클라이언트에 저장된 쿠키 정보) 등
• 응답 헤더의 예시: Content-Type(응답 데이터의 MIME 타입), Set-Cookie(클라이언트에 쿠키를 설정), Cache-Control(캐시 제어 옵션) 등

상태 코드(Status Code)

HTTP 응답에는 상태 코드가 포함되어 있으며, 이는 요청의 처리 결과를 나타냅니다.
상태 코드는 세 자리 숫자로 구성되며, 첫번째 자리는 응답의 성공 여부를 나타냅니다.

• 1xx(정보): 요청이 수신되었으며 처리가 계속 진행 중임을 나타냄
• 2xx(성공): 요청이 성공적으로 처리되었음을 나타냄 (예: 200 OK)
• 3xx(리다이렉션): 요청을 완료하기 위해 추가 동작이 필요함
• 4xx(클라이언트 오류): 클라이언트 요청에 오류가 있음을 나타냄
• 5xx(서버 오류): 서버에서 요청을 처리하는 동안 오류가 발생했음을 나타냄

200번대 : 통신 성공

상태코드	이름	의미
200	OK	요청 성공(GET)
201	Create	생성 성공(POST)
202	Accepted	요청 접수 O, 리소스 처리 X
204	No Contents	요청 성공 O, 내용 없음

300번대 : 리다이렉트

상태코드	이름	의미
300	Multiple Choice	요청 URI에 여러 리소스가 존재
301	Move Permanently	요청 URI가 새 위치로 옮겨감
304	Not Modified	요청 URI의 내용이 변경 X

400번대 : 클라이언트 오류

상태코드	이름	의미
400	Bad Request	API에서 정의되지 않은 요청 들어옴
401	Unauthorized	인증 오류
403	Forbidden	권한 밖의 접근 시도
404	Not Found	요청 URI에 대한 리소스 존재 X
405	Method Not Allowed	API에서 정의되지 않은 메소드 호출
406	Not Acceptable	처리 불가
408	Request Timeout	요청 대기 시간 초과
409	Conflict	모순
429	Too Many Request	요청 횟수 상한 초과

500번대 : 서버 오류

상태코드	이름	의미
500	Internal Server Error	서버 내부 오류
502	Bad Gateway	게이트웨이 오류
503	Service Unavailable	서비스 이용 불가
504	Gateway Timeout	게이트웨이 시간 초과

보안

• HTTP는 기본적으로 평문 통신을 사용하므로 보안에 취약함
• HTTPS(HTTP Secure)는 SSL/TLS를 사용하여 통신을 암호화함으로써 보안을 강화함
• HTTPS는 데이터 기밀성, 무결성, 인증을 제공하여 중간자 공격(MITM)을 방지함
• HTTPS는 웹 사이트 인증서를 사용하여 서버의 신원을 검증하고, 클라이언트와 서버 간의 통신을 암호화함

🧩 REST

REST(REpresentational State Transfer)는 분산 하이퍼 미디어 시스템을 위한 소프트 아키텍쳐 스타일입니다.
REST는 웹의 장점을 최대한 활용할 수 있는 아키텍쳐로, 네트워크 상에서 서버와 클라이언트 사이의 통신 방식을
정의 합니다.

REST는 모든 것을 자원(Resource)로 취급하며, 각 자원은 고유한 식별자(URI)를 가집니다. 클라이언트는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행합니다.

🧩 REST의 주요 특징

1. 클라이언트-서버 구조: REST는 클라이언트와 서버의 역할을 명확히 분리
2. 무상태(Stateless): REST는 클라이언트의 Context를 서버에 저장하지않음. 각 요청은 필요한 정보를 모두 포함해야 하며, 서버는 클라이언트의 요청을 기억할 필요가 없음
3. 캐시 처리 기능: REST는 클라이언트나 중간 서버에서 캐시할 수 있도록 함. 네트워크 효율성을 높이고 클라이언트의 응답 시간을 줄일 수 있음
4. 계층화(Layered System): REST는 클라이언트-서버 사이에 게이트웨이, 프록시, 로드 밸런서 등의 중간 서버를 둘 수 있음. 이를 통해 시스템의 확장성과 보안성을 높일 수있음
5. 인터페이스 일관성: REST는 자원, HTTP 메서드, 자체 설명적 메시지 등을 통해 일관된 인터페이스를 제공
6. Code on demand: 서버에서 소프트웨어 프로그래밍 코드를 클라이언트에 전송해서 클라이언트 기능을 일시적으로 확장 가능

🧩 REST의 장단점

장점

• HTTP 프로토콜 활용: 캐싱, 보안, 압축 등의 기능을 활용할 수 있어 추가적인 장점을 가져갈 수 있음
• 플랫폼 독립성: HTTP 표준 프로토콜을 따르므로, 다양한 플랫폼과 언어에서 REST API를 사용할 수 있음
• 메시지의 명확성: REST는 HTTP 메서드, URI, 미디어 타입 등을 통해 API의 의도를 명확하게 전달
• 클라이언트-서버 역할 분리: 클라이언트는 사용자 인터페이스와 사용자 상태를 관리하고, 서버는 데이터 저장과 비즈니스 로직을 처리

단점

• 표준의 부재: REST는 아키텍쳐 스타일이므로 구체적인 구현 표준이 존재하지 않음
• 상태 관리의 어려움: REST는 무상태 통신을 기본으로 하므로, 클라이언트의 상태 관리가 필요한 경우 구현이 복잡해질 수 있음
• 오버헤드: REST는 각 요청마다 필요한 정보를 포함해야 하므로 메시지 크기가 커질 수 있지만 프로토콜의 압축이나 페이징 등의 기법으로 완화 가능
• 실시간 통신의 제약: REST는 요청-응답 모델을 기반으로 하므로 실시간 양방향 통신에는 적합하지 않을 수 있음

📚 오늘의 회고

앞으로 기술 면접 준비도 해야하는데 중요한 시간을 구현 먼저하면 익숙해지겠지라는 안일한 마음으로 제대로 보지않았던 것들이 많습니다. 지나쳤던 것들을 많이 되돌아보며 정리하는 시간을 가져야겠습니다.