한발 한발 나아가기

HTTP 상태 코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 클라이언트가 인식할 수 없는 상태 코드를 서버가 반환하면, 상위 상태 코드로 해석해서 처리한다.
  • ex) 299 -> 2xx, 451 -> 4xx
• 종류
  • 1xx(information) : 서버가 요청을 클라이언트에서 성공적으로 수신을 했고, 처리 중인 정보를 보낸다.
  • 2xx(Successful) : 서버가 요청을 정상 처리했음을 알린다.
  • 3xx(Redirection) : 요청을 완료하려면 추가 행동이 필요하다.
  • 4xx(Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.
  • 5xx(Server Error) : 서버 오류, 서버가 클라이언트의 요청을 처리하지 못했다.

1xx(information)

• 거의 사용하지 않는다.

2xx(Successful)

3xx(Redirection)

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, location 위치로 자동 이동한다.(리다이렉트)

종류

1. 영구 리다이렉션
   • 리소스의 URI가 영구적으로 이동
   • 원래의 URL을 사용하지 않기 때문에 검색 엔진 등에서 변경을 인지할 수 있다.
   • 301, 308
2. 일시 리다이렉션 : 일시적인 변경
   • 리소스의 URI가 일시적으로 변경
   • PRG 시 사용
   • 302, 307, 303
     • 307, 303을 권장하지만, 302가 이미 상용화되었다.
3. 특수 리다이렉션
   • 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 캐시를 재사용한다.
   • 응답 시 메시지 바디를 포함하면 안된다.(로컬 캐시를 사용하기 때문)
   • 조건부 GET, HEAD 요청 시 사용
   • 304

PRG

• Post / Redirect / Get
• Post 요청 후 새로 고침으로 인한 중복 처리를 방지하기 위해 GET 메서드로 리다이렉트를 한다.
  • 새로고침 해도 결과 화면을 GET으로 조회

4xx(Client Error)

• 오류의 원인이 클라이언트에게 있기 때문에 똑같은 재시도를 하더라도 실패한다.

5xx(Server Error)

클라이언트의 요청 방식

1. 데이터 전달 방식

1) 쿼리 파라미터를 통한 데이터 전송(GET)

2) 메시지 바디를 통한 데이터 전송(POST, PUT, PATCH)

2. 상황에 따른 구분

1) 정적 데이터 조회

• 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회
  • ex) 이미지, 정적 테스트 문서
• GET 사용

2) 동적 데이터 조회

• 쿼리 파라미터를 사용해서 데이터 전달
  • ex) 조회 조건을 줄여주는 필터, 검색 등
• GET 사용
• 주로 필터나 정렬 조건으로 사용

3) HTML Form 데이터 전송

• HTML Form submit 시 데이터 전송
• GET, POST만 지원
• POST Content-Type 종류
  • application/x-www-form-urlencoded
    • form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)
    • 전송 데이터를 url encoding 처리
  • multipart/form-data
    • 파일 업로드 같은 바이너리 데이터 전송 시 사용
    • 여러 종류의 파일을 함께 전송 가능

4) HTTP API 데이터 전송

• HTTP를 사용해서 서로 정해둔 스펙으로 데이터를 주고받으며 통신하는 것이다.
• 웹 클라이언트 - 서버, 앱 클라이언트 - 서버, 서버 - 서버에서 사용한다.
  • 웹 클라이언트는 자바스크립트를 통해 통신한다.(AJAX)
• GET, POST, PUT, PATCH, DELETE 메서드를 모두 지원한다.
• Content-Type은 주로 application/json을 사용한다.

HTTP API 설계 예시

• HTTP API - 컬렉션
  • POST 기반 등록
  • 서버가 리소스 URI 결정(컬렉션)
• HTTP API - 스토어
  • PUT 기반 등록
  • 클라이언트가 리소스 URI 결정(스토어)
• HTML FORM 사용
  • 순수 HTML + HTML form 사용
  • GET, POST만 사용 가능 -> PUT, PATCH, DELETE 대신 POST + 컨트롤 URI 사용

URI 설계 개념

1. 문서(document)

• 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
• ex) /members/100, /files/star.jpg

2. 컬렉션(collection)

• 주로 사용
• 서버가 관리하는 리소스 디렉터리
• 서버가 리소스의 URI를 생성하고 관리
• ex) POST /members로 등록 시, 서버가 임의의 위치(ex. /member/100)에 리소스 생성

3. 스토어(store)

• 파일, 게시판 등에 가끔 사용
• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• ex) PUT /files/100로 등록 시, 서버는 /files/100 위치에 리소스 생성(또는 대체)

4. 컨트롤러(controller), 컨트롤 URI

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
  • 즉, 행위와 자원의 조합만으로는 처리하기 어려운 경우
• URI에 동사를 직접 사용
  • ex) /members/{id}/delete

HTTP

• HyperText Transfer Protocol
• 인터넷상에서 클라이언트와 서버가 자원을 주고받을 때 사용하는 통신 규약
• 거의 모든 형태의 데이터 전송이 가능하며, 서버간에 데이터를 주고받을 때도 대부분 HTTP 사용
  
  • HTML, TEXT
  • IMAGE, 음성, 영상, 파일
  • JSON, XML (API)
• 주로 TCP 기반의 통신 방식
• 특징
  • 클라이언트 서버 구조
  • 무상태 프로토콜
  • 비연결성
  • HTTP 메시지
  • 단순하고 확장 가능

1. 기반 프로토콜

• TCP : HTTP/1.1(가장 많이 사용), HTTP/2
• UDP : HTTP/3

2. 특징

1) 클라이언트 서버 구조

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고, 서버는 요청에 대한 결과를 만들어서 응답
• 클라이언트는 UI, 서버는 비즈니스 로직에 집중할 수 있게 되었다.

2) 무상태 프로토콜(stateless)

• 서버가 클라이언트의 상태를 보존하지 않는다.
  • 중간에 서버가 변경되어도 요청과 응답에 지장이 없다.
• 모든 것을 무상태로 설계할 수 없는 경우도 있다.
  • ex) 로그인을 하는 경우 로그인한 상태를 서버에서 유지해야한다.
  • 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지 가능
  • 전송 데이터양이 증가하기 때문에, 상태 유지는 최소한만 사용
• 장점 : 서버 확장성 높음(스케일 아웃)
• 단점 : 클라이언트가 추가 데이터 전송

3) 비연결성

• HTTP는 기본이 연결을 유지하지 않는 모델이다. 즉, 한 번의 요청과 응답이 끝나면 TCP 연결이 종료된다.
• TCP 기반의 경우 요청할 때마다 연결을 새로 맺어야 한다는 단점이 있지만, HTTP 지속 연결로 이러한 문제를 해소하였다.
  • HTTP/2, HTTP/3에서는 더욱 최적화됨.
• 비연결성 덕분에 서버 자원을 효율적으로 사용.

4) HTTP 메시지

1. start-line
   • request-line(요청 메시지의 경우) : method SP request-target SP HTTP-version CRLF
     • HTTP 메서드(ex. GET)
     • 요청 대상(ex. /search?q=hello&hl=ko)
     • HTTP 버전(ex. HTTP/1.1)
   • status-line(응답 메시지의 경우) : HTTP-version SP status-code SP reason-phrase CRLF
     • HTTP 버전
     • HTTP 상태 코드 : 요청 성공, 실패를 나타냄 (ex. 200)
     • 이유 문구 : 사람이 이해할 수 있는 짧은 상태코드 설명 글 (ex. OK)
2. HTTP 헤더
   • HTTP 전송에 필요한 모든 부가 정보가 포함된다.
     • ex) 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보 등
   • 필요시 임의의 헤더 추가 가능
3. HTTP 메시지 바디
   • 실제 전송할 데이터
   • HTMl 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능

5) 단순하고 확장 가능

3. 문제점

• HTTP는 평문 통신이기 때문에 도청이 가능하다
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
• 완정성을 증명할 수 없기 때문에 변조가 가능하다.

이러한 문제점을 해결하기 위해 HTTPS가 등장했다.