20230527 book

venv와 requirements.txt파일을 사용하여 모두가 동일하게 맞추는 것을 시작
장고가 기본적으로 주는 수많은 파일구조 살펴보기?
- 프로젝트 안에 앱이 있고 거기에 settings.py가 있다.
- urls.py 안에 모든 path에 대한 내용이 담겨있다.
- view.py 안에
- 라우팅 콜백함수 안에 인자를 추가할 수도 있다.

아래는 영민님이 프젝 위주로 책을 집필하려고 할 때 염두한 유즈케이스 기반 목차이다.

—————필수 API—————

도서 목록 조회 API: 도서 목록을 조회하는 API의 구현 방법과 검색, 정렬, 페이징 등의 기능을 포함한 유용한 옵션에 대해 설명합니다.
도서 상세 정보 API: 특정 도서의 상세 정보를 조회하는 API에 대해 다루며, 관련된 데이터와 연결된 다른 리소스에 대한 링크 제공 방법을 소개합니다.
도서 추가 및 수정 API: 새로운 도서를 추가하거나 도서 정보를 수정하는 API의 구현 방법과 필요한 데이터 형식에 대해 설명합니다.
도서 삭제 API: 도서를 삭제하는 API에 대해 안내하고, 삭제 시 연관된 데이터의 처리 방식과 보안에 대해 언급합니다.
도서 추천 및 인기 순위 API(선택): 도서 추천이나 인기 도서 목록을 제공하는 API에 대해 다루며, 추천 알고리즘과 인기 순위를 계산하는 방법을 소개합니다.

API : 재고관리 도서의 재고 상태를 조회하고 관리하는 API를 제공합니다. 사용자가 주문할 때마다 재고가 감소하고, 재고 부족 시 알림을 받을 수 있도록 합니다. API : 주문관리

RESTful하기 위해 DELETE메서드를 사용하려면 ajax 사용해야 한다는게 무슨 말인지 모르겠습니다. self-descriptive하기 위함이라는 것 까지만 이해함.
- 예를 들어 DELETE 메서드의 경우, html에 form 태그로 보낼 수 없다. (POST는 가능함) 그래서 JS 구문이 필요한거고, 이를 비동기적으로 해결해주는 녀석이 바로 ajax인 것.
- DELETE를 그럼 왜 쓰냐? 당연히 메서드 이름과 의도를 매치하기 위해서임. 이것이 true self-descriptive
장고프로젝트를 시작하고 app별로 만들어지는 수많은 파일 (settings.py, view.py...)에 압도당한 기분 ==> 사실 장고 문서 읽으면 해결될 일, 우리가 문서를 읽고 이해하기 쉽게 해석해주는 느낌으로?
model.py <-> view.py 소통창구 이해불가
- import가 단데?
html <-> view.py 소통창구 이해불가 {% %}문법이 html 블럭을 넣는다는것까지만 이해했지만, 그 문법과 장고 백엔드가 서로 어디로 이어지는지 모르겠음.
1. {% url 'app:name' %} 은 app 앱과 그 안에 있는 name 객체(?)를 참조할 수 있음.
2. {% forms.*** %} 하면 어디로 가는거지? 내가 forms를 만들었던가? ==> jinja 구문이 꽤 다양하다. 심지어 {{}}도 있다! 그래서 그쪽 문서도 읽어볼 필요가 있다. 질문 자체에 대한 대답으로는 문법별로 다르다.

전체가 js로 이루어지고 있는 프로젝트가 있는데, ajax 사용예시를 보여준다.
ajax는 비동기 통신으로, 비슷한 예로 axios, fetch가 있다. => 한 화면에서 서버에 통신하면 JS에서 불러오는거.
장고의 뷰는 컨트롤러를 겸한다.

카카오에서 로직을 설계해놓으면 우리 서버에 요청하고 리스폰스 할 수 있게 만들어주기 위해서.

내가 면접관, GPT가 지원자.

평일에 세팅을 해놓고 주말에 같이 동일한 코드를 봐 가면서 API 설계를 진행해보자.