• rest_api
• Status Code
• 정참조, 역참조, related_name
• Django ORM과 SQL의 관계

HTTP request 메세지 구조

1. Start Line

• HTTP Method : 해당 요청이 의도한 액션을 정의하는 부분. 주로 GET, POST, DELETE
• Request Target : 해당 request가 전송되는 url 또는 uri라고도 표현
  👉🏼 REST_API : url을 만드는 아키텍쳐 방식 중에 하나. 이 REST_API에 맞춰서 url을 만들게 될 것
• HTTP version : 주로 1.1 버전 사용
• GET /login HTTP/1.1 : GET 메소드로 login이라는 요청 타겟에 HTTP 1.1 버전으로 요청을 보내겠다

2. Headers

• 요청에 대한 메타데이터(추가 정보)를 담고 있는 부분
• Key : Value 값으로 되어 있음 (JS의 객체, Python의 딕셔너리 형태)
• HOST : 요청을 보내는 타겟의 주소. 즉 요청을 보내는 웹사이트의 기본 주소
• User-Agent : 요청을 보내는 클라이언트에 대한 정보. 어떤 브라우저에서 보내는지
• Content-Type : 해당 요청이 보내는 메세지 body의 타입. 이거에 따라서 body에 담기는 메세지 타입이 달라짐. 2차프로젝트때는 파일 데이터도 다루게 될 것
  그때는 application/json이 아닌 Multipart/form-data타입을 쓰게 될 것
• Content-Length : body 내용의 길이
• Authoraization : 회원의 인증/인가를 처리하기 위해 로그인 토큰을 담는 KEY

3. Body

• 해당 요청의 실제 내용
• 주로 body를 사용하는 메소드는 POST 다
• 헤더의 contetn-type에 따라 달라짐

HTTP response 메세지 구조

1. Status Line

• request 메세지로부터 들어온 요청을 얼마나 잘 처리했는지 상태코드로 반환해주는 곳
• HTTP Version, Status Code, Status Text
• Status Code 도 잘 알아두자!

Django System 구조

1. project 파일

• wsgi.py : 이 파일을 통해 프로트와 서버 통신이 이루어지는 것
• asgi.py : 비동기 통신을 할 때는 이 모듈을 통해 통신함
• my_settings.py : 환경변수로 관리되는 파일이기 때문에 이 안의 SECRET_KEY같은 것을 여기서 직접 import 해오면 안된다 from my_settings import SECRET_KEY 를 바꾸자
  • 방법1 : from project.settings import SECRET_KEY
  • 방법2 : from django.conf.settings import SECRET_KEY 이 방법이 공식문서에서 추천하고 있는 방법

:: Tip. 환경변수 관리하는 방법

기존의 DATABASES는 my_settings.py에 저장되어서 settings.py에서 변수를 import해오는 식으로 썼지만 다른 방법!

• os.environ 이라는 딕셔너리를 통해서 os에 선언되어 있는 모든 환경변수를 가져올 수 있다
• 그러기 위해선 해당 Key들이 os의 환경변수에 등록이 되어 있어야 함
• 터미널에서 vi. zshrc으로 들어가서 export DB_NAME = "westagram" 이런식으로 환경변수를 등록한다
• 그럼 os를 import해서 위처럼 쓸 수 있다
• 이렇게 os에 등록해놓으면 os나 docker에서 실행해도 편하게 사용 가능

2. app의 migrations

• 팀 프로젝트 할 때, 다 똑같은 migrations 파일로 구성을 해야 한다
• ex) A는 0001_initial.py B는 0002_initial.py 가 있으면 충돌 일어남
• migrations해서 PR을 올릴 때는 반드시 몇번씩 확인을 해서 오류가 없는지 확인하고 올리자

3. tests.py

• 2차 프로젝트때는 UnitTest라는 것을 도입함
• 그때 이 모듈에 각각의 엔드포인트들을 테스트 할 수 있는 테스트 코드들을 작성할 것

4. utils.py

• 모든 앱에서 공유해서 쓰는 함수들이나 클래스들을 작성

5. URLconf(urls.py)

• Router : 라우터는 패킷의 위치를 추출하여, 그 위치에 대한 최적의 경로를 지정하며, 이 경로를 따라 데이터 패킷을 다음 장치로 전향시키는 장치. 라우터(Router)는 이름 그대로 네트워크와 네트워크 간의 경로(Route)를 설정하고 가장 빠른 길로 트래픽을 이끌어주는 네트워크 장비

Main urls.py

• 프로젝트 디렉토리에 위치해있다
• urlpatterns 에서 모든 app들을 라우팅해줘야 한다
  ex) path("user", include("user.urls"))

Sub user/urls.py

• 여기서는 타겟이 중요함
  ex) path("/signup", SignUpview.as_view()) signup이 타겟

:: Import 순서 컨벤션

• 첫번째 구역은 built-in 모듈
• 두번째 구역은 외부모듈 - pip install해서 설치한 모듈
• 세번째 구역은 커스텀모듈 - 내가 직접 만든 모듈

6. Error Handling

1) Try, Except

• 이 방법에 if,else보다 더 많은 시간을 쓰기 때문에 가능하면 2번 추천
• get() 함수를 쓰는 경우에는 if,else로 에러를 핸들링할 수 없고 try,except로 넣어줘야 한다
  ex) user = User.objects.get(email=data["email"] 매칭되는 데이터가 없을 시 get함수는 이 user에다가 false를 반환해주는 것이 아니라 그냥 에러를 raise 해버림. 그래서 if, else를 쓸 수 없는 것
• 어떤 경우에도 에러가 발생하지 않는 코드는 try문에서 빼고
• 데이터베이스에 저장을 하는 액션은 보통 내 코드에 문제가 없어도 데이터베이스에 데이터가 중복으로 들어가있거나 하는 가능성이 있는 코드들만 try문 안에 넣어줘야 함
• try, except문 안에 모든 것을 다 넣는 것은 비효율적인 일
• except Exception as e : 이 에러 처리방법은 절.대 쓰지 말자
  • 이유 1 : 에러 메세지를 이렇게 바로 내뱉게어버리면 터미널에서 뜨는 에러 자체가 바로 반환되는 것이기 때문에 사용자 쪽에서 우리 소스코드를 들여다볼 수 있게 됨 = 보안상의 이슈
  • 이유 2 : 디버깅하기가 어렵다. 이렇게 except로 에러를 만들어 놓으면 에러 발생 시 서버가 죽지 않고 살아있으면서 에러를 반환하고 있는 상황. 동시에 사용자는 계속해서 에러를 경험하고 있는 것
    -> except문에 정의해놓지 않은 에러 발생시 : 서버를 죽이고 에러에 대해 빠르게 조치 취하자
  • 보통 이 경우는 logging하는 용도로만 쓰인다

2) if, else

• 이 방법 추천
• get() 대신 filter()를 쓰면 if, else문으로 에러 핸들링 가능 (filter()는 보통 exists()랑 같이 씀)

7. compile() vs match()

• compile한 것을 여러번 쓸 것이 아니면 match를 쓰자 (공식문서 추천)

8. Model

• 국룰 : 대부분의 테이블에 이력 관리 column이 필수다(created_at, updated_at)
• class명 : 대문자로 시작, 단수
• table명 : 복수
• 컬럼의 속성을 정하는 것도 매우 중요하다 null=True, unique=True (이 속성을 두 번 이상 주기 위해서는 multiple unique 속성도 줘야함)
• password 컬럼의 max_length 속성은 암호화될 것을 고려해서 넉넉하게 주자

:: Tip. 추상화된 class 작성

• 이렇게 어느 class에서나 쓰일 컬럼들을 따로 모아서 class로 만든다