https://www.django-rest-framework.org/api-guide/pagination/
아래는 ModelSerializer를 이용한 view를 보여준다
pagination을 적용하기 전
settings에 설정하기
pagination 적용후
.
.
아래는 public 필드를 추가한 모습
search 작업을 할 view
serializer에 필터링 작업을 할 query set 설정
form, model, serializer validation은 서로 비슷하며
각 단계에서 설정이 가능하나 한단계에서 설정하면 다른 부분에서도 같은 효과를 볼수 있으므로 한단계에서 하면 되며 유튜버는 model에서 하는 것을 추천한다.
아래 방법은 validate_필드이름 의 함수를 만들어 validation작업을 하는 것을 보여주고 있다.
위에는 exact를 사용한 방법 아래는 iexact를 사용한 방법이다.
아래는 위와 같은 기능인데 새파일을 만들고 따로 만들어서 관리한 경우이다.
다른 파일에 있는 validator를 import해서 사용한 경우를 보여준다.
아래는 각각 다른 형식의 validator 두개를 만든 예시이다.
rest_framework.validators 안에 제공되는 validator도 있다.
아래는 두개의 validator를 사용한 예제
아래는 EmailField로 지정해서 암묵적으로 validator를 하나더 적용한 예제
아래는 위 예제의 결과 화면
model의 안의 field를 참조해서 새로운 필드를 read_only로 만든 예제
.
.
django에서 제공하는 user에 접근 하는 방법
경로는 settings을 통해 한다.
generics에서는 기본적으로 get_queryset 함수를 제공한다. 이를 수정함으로써 어떻게 데이터를 가져오고 가공할지 결정할수 있다.
model에 user 필드를 추가 함으로써 사용자가 입력 가능하게 된 상태
이를 없애고 django 내부적으로 파악된 user 데이터를 사용하는 방법 아래 아래 부터
model이 만들어 질때 user값을 사용자로부터 받지 말고 내부적으로 처리하는 모습을 보여준다.
serializer에서 user는 제거한다. 내부적으로 처리함으로 필요 없어짐
아래는 수정후 user 필드 입력란이 사라진 모습
ger_queryset을 view 안에 작성해도 되지만 자주 사용하는 코드의 경우 따로 mixin에 정리해준다. 아래는 그 모습
위에 만든 mixin을 import하고 extends하는 모습
아래는 mixin에 사용자 permission관리를 추가한 모습
.
.
아래는 my_user_data 필드를 새로 만들어서 추가하는 예시를 보여준다.
SerializerMethodField의 경우 get_필드이름 의 method를 통해 값을 얻을수 있다.
nested serializer를 방법을 사용했다.
아래는 serializer를 통해 user 필드 값을 얻는 예시를 보여준다.
아래는 위의 필드값을 처리해주는 serializer이다.
nested serializer 사용한 예시
generic UpdateAPIView, DestroyAPIView 사용예시
기본적으로 RetriveAPIView와 사용법이 비슷하다.
아래는 RetriveAPIView 사용 예시
기본적으로 lookup_field는 pk 필드를 이용하는데 다른 필드로 변경할수 있다
.
.
mixin , general api
https://www.django-rest-framework.org/api-guide/generic-views/#mixins
mixins를 import한다
mixins를 사용하는 경우 class view를 사용하게 된다.
그래서 get, post와 같이 form method에 대응하는 함수를 사용할수 있다.
위는 list view 기능을 한다.
아래는 detail, list view 기능을 한다.
아래에서는 detail view기능도 하기때문에 lookup_field 도 사용하게 된다.
pk 가 기본적으로 lookup_field로 사용되며 이는 kwargs 를 통해 전달된다.
아래는 CreateModelMixin을 추가한경우 create 이므로 post 함수를 override해 주었다.
perform_create 함수는 CreatAPIView에 있는 함수이나 CreateModelMixin이 기본적으로 CreatAPIView를 extends하기 때문에 사용 가능하다.
.
.
session authentication and permission
generics을 사용하는 경우
아래와 같이 authentication_classes, permission_classes 를 이용해 지정할수 있다.
function형태에서는 decorator를 이용한다.
.
.
user and group permission . DjangoModelPermissions
아래
DjangoModelPermissions의 경우 기본적으로 모든 사람에게 GET method는 열려 있다. 이를 바꾸기 위해서는 customize를 해야 한다.
.
.
custom permission
.
.
TokenAuthentication
아래는 rest_framework.authtoken 을 표기해주는 과정
rest_framework.authtoken.views의 obtain_auth_token은 사용자가 token을 얻을수 있는 페이지(endpoint)를 만들어준다.
아래 예제에서 사용자가 auth 경로에 접근하면 token을 얻을수 있게 된다.
아래는 TokenAuthentication을 명시해준다.
아래는 사용자가 login해서 token을 얻고 그걸 이용해서 다른 endpoint에 접근가능하게되는 과정을 보여준다.
view에서 사용하는 authentication_classes 에 customized된 authentication class를 사용하기 위해서는 아래와 같이 extends된 class를 만들어 준다.
customized된 authentication class를 가져와서 연결해 준다.
.
.
default setting
DEFAULT_AUTHENTICATION_CLASSES
DEFAULT_PERMISSION_CLASSES를 REST_FRAMEWORK 안에 설정해서 매 view마다 설정하던것을 기본설정할수 있다.
아래는 authentication_classes, permission_classes를 view단위에서 설정한 모습
아래와 같이 setting에 기본설정할수 있다.
DEBUG 모드일경우 다르게 설정하고 싶으면 아래와 같이 할수도 있다.
default로 설정하고 view에서는 내용을 생략한 경우이다
.
.
mixin 을 사용 반복되는 코드 없애기
아래는 mixin을 사용하기 전의 모습
permission_classes 부분을 매 view마다에서 작성해 주었다.
아래는 mixin에 포함될 permission class
mixin class 만들기
view class는 mixin class를 extends하고 기존에 있던 반복되는 코드를 생략한다.
.
.
viewsets 과 routers를 이용해 url들을 쉽게 만들수 있다.
위 register에서 사용한 ‘products-abs’는 아래 같이 경로에서 사용된다.
아래의 경우 list, detail endpoint를 만들려고 하지만 router를 사용하는 경우 더 많은 endpoint url이 생긴다. 결론적으로 404 endpoint가 쓸데 없이 생긴다는 이야기이다. 이를 막기 위해서는 아래아래 방법을 사용한다.
.
.
url field 만드는 방법 3가지를 보여준다.
1 방법
2방법 reverse를 사용한 방법
아래 reverse에 들어간 product-detail은 urls에 있는 name 값이다. 아래아래 그림 참조
3방법
HyperlinkedIndentityField 를 이용한 방법
.
.
아래에서 email은 사용자로부터 입력을 받을수는 있지만 실제 model에는 없는 필드이다.
ModelSerializer는 기본적으로 create, update 메소드를 가지고 있으며 사용자가 새로운 model을 만들때는 create가 실행되고 수정할때는 update가 실행된다. 이때 필요한 추가 작업을 할수 있다
.
.
기본적으로 model, form, serializer의 validation하는 방법은 비슷하며 여러겹을 각 단계별마다 validation을 설정해도 되지만 굳이 여러단계에서 할 필요 없이 한단계에서 처리해도 된다.
virtual env 만들기
linux에서는 scripts가 아니고 bin
이 프로젝트에서 사용한 디펜던시
requirements.txt 안의 dependencies를 설치하는 경우
django proj시작
http get 메소드로 params abc , json query가 전달되는경우
서버쪽에서 전달된 json은 request.body에 들어 있으며 이는 byte string 형식으로 전달되는데 json.loads()를 통해 python dictionary로 전환 가능하다.
request에는 header, content_type정보도 있다.
get , post메소드로 전달되어 들어오는 파라미터 값은 request.GET, request.POST를 통해 접근 가능하다.
위와 아래는 같은 기능을 한다.
.
.
django에서 json으로 값 리턴하기
위와 같이 할수도 있지만(특정 데이터 타입은 javascript에 있지 않기 때문에 이런 경우는 손수 전환을 해야한다) 해야 할일이 많다.
간단하게 아래와 같이 하면 된다.
.
.
위의 방법들 같이 해도 되지만 좀더 편하게는 rest_framework의 @api_view 데코레이터를 이용할수도 있다.
return Response에서 Response가 rest_framework.response인것에 유의
.
.
아래는 model에 함수형태의 field를 추가한 모습
아래는 django form 을 이용하는 방법. 이는 serializer를 만드는 방법과 매우 유사하다.
validation기능이 있는 것도 매우 유사
아래는 model에 없는 field를 serializer에 추가 하는 모습이다.
.
.
https://youtu.be/c708Nf0cHrs?t=5160
model과 serializer가 아래와 같다고 했을때
아래 model에서 title은 required field이다.
http request는 아래와 같다고 한다면 (필수 항목인 title값이 없음)
아래와 같이 view를 처리하면 title 값이 주어지지 않았으므로 serializer.is_valid는 실패하고 “invalid nott= good data” 가 json 형식으로 사용자에게 되돌려 진다.(Response는 rest_framework의 Response함수임) 그러나
아래와 같이 raise_exception = True를 하면 좀더 자세한 왜 에러가 발생했는지 json 형태로 사용자에게 알려 준다.
.
.
Generic RetrieveAPIView
view를 만든 모습 굉장히 간단하다. 숨겨진 부분이 많다.
as_view()를 사용하거나 아래 아래와 같이 view 파일에서 변수안에 함수로 저장한 다음 그걸 import하고 그걸 url에서 사용해도 된다.
아래는 테스트 request를 하는 코드이다.
.
.
generic CreateAPIView
while executing generic CreateAPIView , we can do more jobs. this is like webhook
.
.
generic ListAPIView 를 통해서 아이템 리스트를 보여주는 view를 만들수 있다.
그러나 ListCreateAPIView와 결과적으로 기능이 같다. 설명해주는 사람은 ListCreateAPIView를 사용한다고 한다.
.
.
위에서 generic views들로 작업한 것을 일반 함수형태로 재구성한 방법
아래는 retrieve, list를 재현한것
아래는 create를 재현한것이다.
.
.
generic UpdateAPIView, DestroyAPIView 사용
기본적으로 RetrieveAPIView와 유사하다.
아래는 RetrieveAPIView의 사용 예시. 기본적으로 lookup_field 는 pk 이다. 이를 기준으로 작동한다. 변경을 위하면 다른 field로 지정해 주면 된다.
아래 작업전 virtualenv를 이용해서 작업 공간을 만든다.
pip 으로 설치한 디펜던시 requirements.txt에 저장하기
.
.
2강 https://youtu.be/uzO2PW5jNMk
서버에서의 객체를 외부로 보낼때 serializing 작업을 해서 내보내고
서버로 들어온 데이터를 deserializing을 해서 객체로 만들어서 작업한다.
serializer는 두가지가 있으며
아래는 일반 serializer를 보여주고 있다.
아래는 위 보다는 간단한 model serializer를 보여주고 있다.
rest framework를 사용하는 경우 폴더를 따로 만들어 관리하는 것이 좋다.
이 예제에서는 api 폴더를 만들었고 모든 python 프로젝트 내의 폴더는 __init__.py를 가지고 있어야 python이 폴더로 인식을 한다.
.
.
3강
rest_framework를 이용한 view의 형식
rest framework 를 위한 app urls
전체 urls에 app urls을 추가하는 경우
.
.
4강
put , delete, post 처리 view 예시를 보여주고 있다.
serializer를 이용해서 update하기
https://stackoverflow.com/questions/69071531/how-to-use-django-serializer-to-update-an-instance
put 을 이용해서 update한다.
dictionary 형태로 데이터를 Response()함수에 넣어주면 json 형태로 클라이언트에게 전달된다.
(참고) serializer partial update
https://www.django-rest-framework.org/api-guide/serializers/#partial-updates
.
.
6강
https://www.django-rest-framework.org/api-guide/serializers/#additional-keyword-arguments
sign up , registration, register
serializer의 save()를 오버라이드해서 저장될때 작업을 추가 할수 있다.
https://www.django-rest-framework.org/api-guide/serializers/#additional-keyword-arguments
위에서는 extra_kwargs를 사용해서 password는 입력받아 obj를 생성하지만 저장되어있는 obj를 사용자에게 보일때는 password는 보이지 않게 한다.
.
.
7강
authentication token
https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication
아래는
settings, post_save_receiver 그리고
rest_framework에서 Token 모델을 가져온 모습
사용자 user account 가 만들어 질때 마다 receiver가 작동해서 아래 코드를 수행한다.
여기 예제에서는 매번 사용자가 만들어질때마다 token이 만들어져 저장된다.
post_save : https://docs.djangoproject.com/en/3.0/ref/signals/#post-save
.
.
8강
authentication과 permission을 조합해서 사용하는 경우
이 예제 프로젝트에서는 token authentication으로 확인된 사용자가 특정 페이지 작업을 할수 있게 하는 것을 보여준다.
아래는 permission작업을 authentication을 이용해서 한다는 내용
아래는 decorators permission_classes, rest_framework.permissions에서 IsAuthenticated를 가져온것을 보여준다.
아래의 경우 django가 알아서 token을 통해 서버내에서 사용자를 찾아서 request.user에 넣어준다.
.
.
9강
Serializer에 field를 추가 하는 경우
아래는 BlogPost model을 기반으로한 serializer에다가 username field를 추가하는 경우이다. get_username_from_author 함수를 이용해서 username 값을 만들수 있다.
.
.
10강
pagination
settings.py에 REST_FRAMEWORK 내용을 추가해준다.
views.py에서 필요한 라이브러리 import한다.
class view를 이용한 경우를 보여주고 있다.
class view를 urls에 추가하는 경우 as_view()를 이용한다
아래는 결과모습이다. 아래와 같이 json 형태로 각 페이지에 필요한 데이터를 내보낸다.
사용자 login, sign up 을 쉽게 하기위한 라이브러리 설치
allauth를 사용하기 위해 아래 같이 settings 에 설정
allauth를 위해 app 설정
allauth url설정
login, signup등의 과정을 수정하기 위해 adapter를 만들어서 settings에 설정해준다.
signup을 사용하지 않겠다고 설정한 코드
보기 좋은 ui를 위해 crispy-form 라이브러리 설정
crispy form 설정해준다.
crispy form중에서도 bootstrap 형식을 사용한 경우
all auth에서 제공해주는 template을 찾아서 직접 복사 붙여넣기를 하려고 웹사이트에서 폴더를 찾은 모습
기존의 template외에 추가 template을 사용하기 위해 경로를 추가 해 주었다.
login 후 landing url을 설정해 주었다.
login 후에 landing될 view를 만든 모습. 일반 view와 크게 다르지 않다.
다른 앱의 url을 가져와서 추가하는 경우 include사용한다. import를 해주어야 사용 가능
setting에 기입했던 LOGIN_REDIRECT_URL의 값이 dashboard였고 아래보면 dashboard가 무엇인지 설정한걸 볼수 있다.
filter의 여러 and구문은 , 를 이용한다.
아래에서 test_func는 아래아래에서 LoginRequiredMixin에서 사용된다.
1강
.
.
2강
image 처리를 쉽게 하기위해 pillow library 사용
media url 추가
model 사용
migrate , migration
admin에 app 추가하기
view 처리
csrf token form에 추가하기
.
.
4강
view 역할하는 함수에 파라미터 전달하기
아래 그림 ajax로 post하는 경우 csrf token을 얻는 방법
아래 그림 ajax를 이용하는 방법
view역할 하는 함수에서 파라미터 전달받아서 이를 이용하는 과정
