깔끔한 파이썬 탄탄한 백엔드 - #4 HTTP의 구조 및 핵심 요소

면접에서도 자주 나오는 질문 중에 하나인 HTTP의 구조에 대한 내용이다.

책을 읽어보니 내가 생각보다 알고 있던 게 거의 없었다. 새로 배우는 듯한 느낌. ㅠㅠ

그러니 제대로 대답을 못했었지..

 

HTTP 통신방식의 특징

- Request, Response로 이루어져 있음

- 상태가 없음(stateless) : 한 번 통신하면 끝. HTTP 요청을 보낼 때 필요한 모든 데이터를 매번 포함시켜 보내야 함. 예를 들어 인증된 사용자만 접근할 수 있는 API인 경우 인증에 대한 정보를 포함해야 함. 이를 해결하기 위해 세션 혹은 쿠키를 사용함. 세션은 서버에 저장, 쿠키는 클라이언트에 저장.

 

다음은 HTTP Request/Response의 구조에 대해 알아본다.

Postman을 쓰면서 구조 자체는 익숙하기는 하나, 세부 사항에 대해서는 몰랐었다.

그래서 이번 기회에 꽤 많은 지식을 쌓은 듯.

 

HTTP Request 구조

- Start Line : HTTP Request의 시작 줄. POST /like HTTP/1.1과 같이 메서드, 타깃(주소), 버전으로 되어있다.

- Headers : Key-Value 형태로 되어있으며 세부사항은 아래와 같다.

  1. HOST :  호스트 정보.

  2. User-Agent : 클라이언트에 대한 정보(웹 브라우저 등)

  3. Accept : 해당 요청이 받을 수 있는 Response body 타입. MIME type이 value로 지정되며, MIME type 중 주로 쓰는 것은 application/json, octet-stream, xml, text/csv, html, plain, image/jpeg, png 등이 있다.

  4. Connection : 해당 요청이 끝난 뒤 클라이언트와 서버가 계속 연결을 유지할 것인지에 대한 정보. keep-alive면 연결 유지. close는 연결 종료.

  5. Content-Type : 요청이 보내는 body의 타입을 알려주는 헤더. MIME type이 사용됨

  6. Content-Length : 요청이 보내는 메시지 body의 총사이즈를 알려주는 헤더

- Body : 데이터를 담고 있는 부분. MIME type이 application/json인 경우 json형태의 object로 존재.

 

HTTP Response 구조

- Status Line : 응답 메시지의 상태. 버전, 상태 코드, 상태 텍스트 형태로 구성. 예를 들면 HTTP/1.1 404 Not Found

- Headers : Request의 헤더와 동일. 그러나 Response에서만 사용되는 헤더 값들이 존재. User-Agent 대신 Server 헤더가 사용됨

- Body : 요청 메시지의 body와 동일. 데이터가 없으면 비어있음

 

HTTP 메서드 : GET, POST, PUT, DELETE는 많이 구현해봤어서 크게 설명할 건 없을 것 같다.(sql의 select/create/update/delete 와 유사)

- OPTIONS : 특정 엔드포인트에서 허용되는 메서드들이 무엇이 있는지 알고자 하는 요청에서 사용되는 메서드. 허용되지 않는 메서드의 요청이 들어오면 405 Method Not Allowed를 받게 됨.

 

자주 보게 되는 HTTP 상태 코드 및 상태 텍스트

- 200 OK : 문제없을 때

- 301 Moved Permanently : URL 주소가 바뀜을 나타내는 코드. 리다이렉션에 사용

- 400 Bad Request : 잘못된 요청일 때. 주로 입력된 값들에 이상이 없을 때 받게 되는 코드

- 401 Unauthorized : credential 확인이 요구되거나 확인 불가할 때. 로그인이 필요한 경우 받게 되는 코드

- 403 Forbidden : 권한이 없음을 나타내는 코드. 401은 아예 로그인이 안돼서 정보가 없는 걷고, 403은 로그인은 되어 있으나 권한이 없는 거라 둘 간에 차이가 있음.

- 404 Not Found : URI가 존재하지 않을 때 발생하는 코드. 페이지를 찾을 수 없습니다.라고 인터넷 서핑하다 보면 자주 보게 되는 코드 중 하나.

- 500 Internal Server Error : 내부 서부 오류가 발생함을 알려주는 코드. 이 코드가 생각보다 디버깅이 까다로운 경우가 많음 ㅠㅠ

 

API 엔드포인트 아키텍처 패턴

- RESTful HTTP API : 난 이거 하나만 있는 줄.. 그냥 내가 이미 알고 있는 HTTP 메서드를 사용하여 API 설계하는 방법. 직관적으로 간단해지나, 호출 수가 많아짐.

- GraphQL : 난 이게 SQL 관련 기술인 줄 알았음. ㅋㅋㅋ. API 엔드포인트 아키텍처 패턴이라니.. REST API를 개발하다 보면 클라이언트에서 여러 번 호출을 해야 할 것 같은 상황이 자주 생기는데(예를 들어 로그인한 사용자의 정보도 받아야 하고 그 사용자와 연관된 건강 정보 등을 받아야 하는 경우 - 그래서 두 번 호출하지 않도록 ORM 쪽 코드를 복잡하게 구성하는 경우가 존재) GraphQL을 사용하면 한 번에 요청을 보내고 한 번에 응답을 받을 수 있어서 용이한 듯. API 개발 시간이 줄지 않을까 싶음. 사용하는 곳이 많지는 않아서 아직 적용하기는 시기상조일 듯? 프런트엔드 쪽에서의 적응도가 더 중요할 듯한 기술인 것 같다.

 

오랜만에 공부 다운 공부를 한 것 같다. 내가 생각보다 모르는 게 많았다는 걸 깨달았던 하루.