TIL 2023.04.18

HTTP와 웹의 동작 방식

웹의 역사

HTTP의 이해

백엔드 개발할 때 추구하는 방향

 

1. DRF(Django REST Framework) 소개 - 프론트엔드와 백엔드를 나눈다는 의미
   1. 프론트와 백엔드 레포지토리 따로 만들고 AJAX로 Json 데이터를 주고 받는다
   2. 템플릿은 더이상 작성을 하지 않게 된다
   3. 장고 템플릿 랭귀지도 사용하지 않게 된다
   4. 자바스크립트를 이용해 작성하게 된다
   5. drf에서 모든 과정을 간단하게 살 수 있게 도와준다
2. 포스트맨설치 - Request와 Response 살펴보기
   1. 다양한 HTTP 요청을 보낼 수 있다
   2. 네이버(https://www.naver.com/)를 GET 요청으로 보냈을 때 정보를 받아올 수 있었다
   3. Request가 우리가 보낸 거 Response가 우리가 받은 거
   4. Console을 통해 어떤 정보를 주고 받았는 지 볼 수 있다.
   5. curl 로 터미널을 통해서도 웹사이트에 접속할 수 있다.
   6. 우리가 받은 정보를 눈으로 볼 수 있게 바꿔주는 게 웹브라우저의 역할
   7. 우리가 단순하게 주소창에 url 입력한 게 사실은 복잡한 요청이 있었다
   8. 그런 복잡한 요청을 브라우저가 간단하게 만들어주고 있었다
   9. 그런 요청을 포스트맨에서 여러 개 만들 수 있다
   10. 포스트맨에서 간단하게 새로운 api들을 만들면서 서비스 만들 때 작성된 걸 가지고 편리하게 볼 수 있다.
3. HTTP - 웹의 요청 흐름 살펴보기
   1. 우선 가장 근본적인 웹의 흐름은 클라이언트가 있고 서버가 있습니다
   2. 클라이언트가 크게 보면 컴퓨터 구체적으로 보면 크롬, 포스트맨 같은 거 핸드폰. 앱
   3. 무언가 요청 request 요청을 서버에 보냅니다
   4. 서버는 네이버 다음 등
   5. 그럼 response 응답을 작성해서 돌려줍니다
   6. 아무렇게나 써서 보내면 알아들을 수 없고 아무렇게나 돌려주면 알아볼 수 없습니다
   7. 그런 해석을 어떻게 할지 정해놓은 약속이 있습니다
   8. 그걸 HTTP 라고 부릅니다 HyperText Transfer Protocol
   9. 웹브라우저의 흐름
      1. DNS 조회 (도메인 네임 시스템) 주소록과 비슷함 nslookup 명령어로 IP 확인 가능
      2. HTTP 요청 메시지 작성 GET header ~ POST는 body도 존재
      3. Socket 라이브러리를 통해서 전달
      4. TCP/IP 작성되고 이 안에서 HTTP 메시지가 포함
   10. 프로토콜 계층 어플리케이션->소켓라이브러리->TCP->IP->LAN->인터넷
   11. IP 인터넷 프로토콜
       1. 지정한 ip 주소로 전송
       2. 출발지 IP와 목적지 IP 작성
       3. 송신하면 노드들을 거쳐서 송신이 된다
   12. TCP
       1. IP를 TCP로 보완한다
   13. UDP(UDT아님)
   14. Port 8000번 뭐시기
   15. URI Uniform Resource Identifier
       1. URI > URL URN
       2. 포트 생략시 http는 80 https는 443
4. HTTP - HTTP 메시지의 구조 살펴보기
   1. HyperText Transfer Protocol
   2. 원래는 HTML 전송용으로 나왔으나 현재는 모든 형태를 전송한다.
   3. 팀 버너스리
   4. 웹의 시작
   5. html에서 어떤 글자를 눌렀을 때 다른 html을 보여주게 하자 그럼 모든 html이 연결되는 world wide web이 될거다
   6. css js 도 생김 여러 프레임워크 웹서비스 애플리케이션
   7. 역사
      1. 1991년 GET 메소드만 지원, 헤더가 없음
      2. 1996년 메소드와 헤더 추가
      3. 1997년 HTTP 1.1 버전 나옴
      4. 2015년 HTTP2 성능 개선
      5. 2020년 HTTP3
   8. 특징
      1. 클라이언트 서버 구조
         1. 리퀘스트 리스폰스 구조
         2. 클라이언트는 리퀘스트를 보내고 리스폰스를 기다리게 된다
         3. 클라이언트에 ui 다 넣고 drf 백엔드에서 로직을 넣어
      2. 무상태 프로토콜 stateless
         1. 서버가 클라이언트 상태를 보존하지 않는다
         2. 한 점원이냐 매번 다른 점원이냐
         3. 중간에 다른 점원으로 바뀐다고 생각해야 한다
         4. 무상태는 응답서버를 쉽게 바꿀 수 있다
         5. 세션 로그인은 상태가 있다. 최소한으로만 사용한다는 개념
      3. 비연결성
         
         1. 요청시마다 연결을 유지하면 클라이언트가 연결을 하면 할수록 서버가 터진다
         2. 연결 유지를 하지 않으면서최소한의 자원 사용을 할 수 있다
         3. HTTP는 기본적으로 연결을 유지하지 않는다
         4. 일반적으로 초단위 이하의 빠른 응답
         5. 1시간동안 수천명이 써도 실제 동시처리하는 요청은 몇십개도 안된다
         6. 서버 자원을 효율적으로 쓸 수 있다
   9. HTTP 메시지
      1. 요청메시지랑 응답메시지는 다르게 생겼다
      2. 포스트맨으로도 확인 가능하다
   10. HTTP Method
       1. 안 좋은 설계: 각각 url 주소 다 만들어서 처리하는 것
       2. 가장 중요한 것은 리소스 식별!
       3. 리소스란? 회원이라는 개념 자체가 리소스다 이것이 URI에 매핑이 되는 것이다. 거기에 하는 해우이는 메소드로 하는 것이다.
       4. 회원목록 조회 /members 회원조회 /members/{id} 등록/members/{id} 수정 ~ 삭제 ~
       5. 리소스(회원)와 행위(조회등록수정삭제)를 분리하는 것이 Restfull API
       6. 메소드
          1. GET: 조회. 바디가 없기 때문에 주소창으로만 전달 쿼리스트링
          2. POST: 등록. 메시지 바디를 통해 서버로 요청 데이터 전달
          3. PUT: 대체 혹은 생성. 파일 붙여넣기와 동일, 없으면 만들고 있으면 덮어쓴다. 포스트와 차이점은 풋은 클라이언트가 URI 지정해서 보낸다. 제목만 수정하고 싶어도 전부 다 보내야함
          4. PATCH: 부분 변경. 제목만 바꾸고 싶으면 제목만 보내면 돼
          5. HEAD: GET과 동일하지만 상태줄과 헤더만 반환
          6. DELETE
       7. 데이터 전송
          1. HTML form: get과 post만 지원
          2. HTTP API
             1. 회원가입, 주문, 데이터 변경
             2. 서버 to 서버, 앱 클라이언트, 웹 클라이언트(ajax)
             3. 폼 대신 JS를 이용한 통신
             4. post put patch 도 메시지 바디로 데이터 전송 가능
   11. HTTP 상태 코드
       1. 1xx 요청이 수신되어 처리 중
       2. 2xx 요청 정상 처리
          1. 200 OK
          2. 201 Created
          3. 202 Accepted
          4. 204 No Content
          5. 보통 200과 201 사용
       3. 3xx 추가 행동 필요
          1. 리다이렉트 해줄 때 나오게 됨
       4. 4xx 클라이언트 에러
          1. 잘못된 문법
          2. 400 요청 내용을 다시 검토해야 한다
          3. 401 인증이 안됨 ( 로그인이 안 돼 있다.)
          4. 403 권한이 없다 ( 로그인 됐으나 운영진이 아니다)
          5. 404 리소스가 없다 또는 숨기고 있다
       5. 5xx 서버 에러
          1. 복구 후 재시도시 성공 가능하다
          2. 500 서버 내부 문제
          3. 503 서버가 일시 과부하
5. HTTP - HTTP의 다양한 헤더들 살펴보기
   1. 종류가 굉장히 많다.
   2. 필드네임(key)는 대소문자 구분 없다
   3. http 전송에 필요한 모든 부가정보
      1. 바디 내용
      2. 바디 크기
      3. 압축
      4. 인증
      5. 요청 클라이언트
      6. 캐시 관리
   4. 표준 헤더가 너무 많고 필요시 임의의 헤더도 추가 가능하다
   5. 바디 데이터 해석할 수 있는 정보 제공
   6. 쿠키
      1. HTTP는 무상태 연결이기에 상태를 매번 보내줘야한다
      2. 모든 요청과 링크에 사용자 정보를 포함해야 한다는 단점이 있다
      3. 이를 해결하기 위해 쿠키가 도입됐다
      4. Set-Cookie 너희 브라우저에 쿠키 만들어줘
      5. Cookie
   7. Cache
      1. 캐시가 없다면 매번 같은 요청이 와도 헤더와 바디를 새로 보내준다
   8. 외워서 쓸 필요 없고 필요할 때 찾아보면 된다.

 

DRF 공식 문서 - https://www.django-rest-framework.org/

Home - Django REST framework

swagger - https://drf-yasg.readthedocs.io/en/stable/readme.html

drf-yasg - Yet another Swagger generator — drf-yasg 1.20.1 documentation

장고 cors - https://pypi.org/project/django-cors-headers/

django-cors-headers