스파르타 코딩클럽 내일배움캠프 AI 웹개발자양성과정 3회차
2022.10.24. 37일차 - TIL
1. 장고 심화 원격 강의
1) 목표
프론트엔드와 백엔드의 역할 이해하기HTTP 메시지의 구조 이해하기Request와 Response 메시지 역할 이해하기HTTP의 상태코드 역할 이해하기HTTP의 헤더 역할 이해하기웹의 요청 흐름 이해하기State와 Stateless 뜻 이해하기Restful한 API 설계하기
프론트와 백엔드 분리
여태까지 사용한 방식은 Django의 MTV(Model-Template-View) 방식으로 약간 올드한 방식이다. Django의 MTV에 대해 복습하자면 다음과 같다.
- 유저가 특정 url로 요청을 보낸다.
- urlConf를 통해 해당 url과 매핑된 뷰를 호출한다.
- 호출된 뷰는 요청에 따라 적절한 로직을 수행하며 그 과정에서 모델에게 CRUD(Create, Read, Update, Delete)를 지시한다.
- 모델은 ORM을 통해 DB와 소통하며 CRUD를 수행한다.
- 그 후 뷰는 지정된 템플릿을 렌더링한다.
- 최종 결과를 응답으로 반환한다.
하지만, 여기서 문제가 발생했으니 바로 5번에서 뷰는 지정된 템플릿을 렌더링한다는 것이다. 렌더링 할 때 백엔드에서 전송하고자 하는 정보를 context에 담아 보내면서 필요없는 부분까지 함께 다시 가져와 보여주어야 한다. 그래서 우리는 프런트와 백을 명확하게 분리하고 이 둘을 서로 통신할 때 Django Rest Framework를 이용해 Data JSON을 주고 받는다.(드디어.. 등장하는구만... REST FRAMEWORK....)
Request와 Response 살펴보기
일단, 포스트맨을 설치한다. 포스트맨이란 다양한 HTTP 요청들을 보낼 수 있는 API 개발 플랫폼이다. 이제 하나하나 값을 입력해 실행을 확인하는 게 아니라 postman으로 API Request를 미리 설정해 개발을 더 용이하게 할 수 있다.
Request : 클라이언트가 서버로 전달하는 메시지로 서버측 액션을 유도한다
Response : 요청에 대한 서버의 답변
웹의 요청 흐름 살펴보기
클라이언트가 서버에게 Request 요청을 보내면 서버로부터 Response를 받는다. 이런 request와 response는 무작위로 보내는 것이 아닌 받는 이가 이해하기 쉽도록 하는 규칙이 있는데 이것을 프로토콜, 즉 HTTP라 한다. 초기 HTTP는 HTML을 전송하기 위해 고안된 개념으로 Header와 Body의 양식이 있다. 웹브라우저의 흐름은 다음과 같다.
- DNS(Domain Name System) 조회(ex. 검색창에 naver.com을 입력) : 인터넷 어딘가에 도메인 네임 서버가 존재하는데 해당 서버에서 도메인 명을 IP주소로 변환
- HTTP 요청 메시지 작성 : GET/POST
- Socket 라이브러리를 통해서 전달
- TCP/IP 작성되고 이 안에서 HTTP 메시지 포함
아래는 그냥 개념으로만 정리해두자.
- 프로토콜 계층
- 어플리케이션 -> socket library -> TCP -> IP -> LAN -> 인터넷
- Internet Protocol
- 지정한 IP주소로 전송
- 출발지 IP와 목적지 IP를 작성
- 송신하면 노드들을 거쳐서 송신이 된다 -> 한번에 목적지까지 가지 않고 여러군데를 걸쳐 간다
- But, 받을 대상이 없을 수도 있다
- 중간에 패킷이 손실되거나 순서대로 오지 않을 수 있다
- 같은 IP를 사용하는 어플리케이션이 여러개라면 문제가 생긴다
- TCP
- IP를 TCP로 보완한다
- 출발지 Port와 목적지 Port 정보
- 전송제어와 순서
- 검증 정보 등이 실린다
- 연결지향 TCP 3 way handshake 를 통해 연결이 되었는지를 먼저 확인한다
- 데이터 전달을 보증한다
- 순서를 보장한다
- 신뢰할 수 있어서 현재 대부분 TCP를 사용한다
- TCP 3 way Handshake
- 클라 -> 서버 : SYN
- 서버 -> 클라 : SYN + ACK
- 클라 -> 서버 : ACK
- SYN을 통해 연결, ACK를 통해 승인
- 최적화를 통해 요즘은 3단계에서 데이터 송신을 한다
- UDP(User Datagram Protocol)
- 기능이 거의 없고
- TCP 기능들이 없다
- IP와 유사한데 포트와 체크섬만 추가됐다
- 어플리케이션에서 추가 작업이 필요하다
- 원하는 기능들을 추가해서 만들 수 있는 하얀 도화지 같은 프로토콜이다
- Port
- 한 컴퓨터에서 게임 화상통화 웹브라우저를 다 킬 수 있다
- 포트는 같은 IP 내에서 프로세스 구분을 해줄 수 있다.
- 0~65535이 존재
- 0~1023은 잘 알려진 포트로 사용하지 않는게 좋다
- DNS
- IP는 변경될 수 있다
- 도메인명을 이용해 주소록처럼 이용
- URI와 웹브라우저 요청 흐름
- URI은 locator, name 또는 둘다 추가로 분류될 수 있다
- URI라는 개념 아래 URL과 URN이 존재한다
- URN은 거의 쓰이지 않는다
- URL
- 포트 생략 시 HTTP는 80, HTTPS는 443
- 리소스 경로는 계층적 구조로 이루어져 있다
- fragment : 페이지 내에서 위치
- HTTP
- 원래는 html 전송용으로 나왔으나 현재는 모든 현태를 전송
- 이미지, 음성, 영상, 파일, JSON, XML etc
HTTP 메시지의 구조 살펴보기
HTTP의 특징은 클라이언트 서버 구조로 되어있고, Stateless하다는 것이다. 클라이언트 서버 구조란 클라이언트가 Request를 보내고 Response를 기다리는 구조를 말한다. 클라이언트와 서버의 개념을 분리하면서 FE와 BE를 독립적으로 관리할 수 있다. 무상태 프로토콜(stateless)란 서버가 클라이언트 상태를 보존하지 않는 개념으로 응답서버를 쉽게 바꿀 수 있어 자원의 효율적 사용이 가능하지만 매접속마다 상태 정보를 알려야 한다는 단점이 있다. 하지만 세션 로그인은 상태를 보존하고 있다.(최소한만 사용)
Request message = Request Line(=HTTP메소드+URL+HTTP버전) + Header + A Blank line + Body
Response message = Status Line(=HTTP버전+상태코드+상태텍스트) + Header + A Blank line + Body
여태까지 우리는 기능별로 url을 부여해 처리했지만, 앞으로는 리소스를 식별해 url에 매핑하고 거기에 하는 행위는 메소드로 구현한다. 예를 들면 회원이라는 개념을 /user 로 url에 매핑하고, 로그인, 회원가입 등의 메소드를 구현한다.
메소드 종류
(1) Get(조회)
- 데이터는 쿼리스트링으로 전달
(2) Post(등록)
- 메시지 바디를 통해 데이터 전달 및 서버로 요청
- JSON으로 조회 데이터를 넘기고 싶은데 너무 길어 GET 메서드를 쓰기 어려운 경우도 이용 가능
- GET은 캐싱을 할 수 있어 가능한 경우 GET을 사용
(3) Put(대체 혹은 생성)
- 파일 붙여넣기와 동일, 없으면 만들고 있으면 덮어쓴다
- 클라이언트가 URL을 지정해 보낼 수 있다
(4) Patch : 부분 변경
(5) Head : Get과 동일하지만 상태줄과 헤더만 반환
데이터 전송 방법
(1) HTML Form
(2) HTTP API
API 설계 예시
- 회원 관리 - 컬렉션 기반
- GET /members -> 회원 목록
- POST /members -> 회원 등록
- GET /members/{id} -> 회원 조회
- PATCH, PUT, POST /members/{id} -> 회원 수정
- DELETE /members/{id} -> 회원 삭제
HTTP 상태코드
자주 사용되는 몇개는 기억해두자.
HTTP 헤더
HTTP 헤더에 담기는 내용은 아주 많고 다양하기 때문에 필요할 때 공식 문서에 찾아가 확인한다.
참고자료
https://tibetsandfox.tistory.com/16
https://velog.io/@bky373/Web-HTTP%EC%99%80-HTTPS-%EC%B4%88%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
https://developer.mozilla.org/ko/docs/Web/HTTP/Headers
'개발일지 > AI 캠프' 카테고리의 다른 글
내일배움캠프 AI - 39일차 TIL, 2022.10.26 (0) | 2022.10.26 |
---|---|
내일배움캠프 AI - 38일차 TIL, 2022.10.25 (0) | 2022.10.26 |
내일배움캠프 AI - 8주차 WIL (0) | 2022.10.23 |
내일배움캠프 AI - 36일차 TIL, 2022.10.21 (0) | 2022.10.23 |
내일배움캠프 AI - 35일차 TIL, 2022.10.20 (0) | 2022.10.21 |