Django for APIs는 Django 및 Django REST Framework를 사용하여 최신 API를 빌드하기 위한 프로젝트 기반 가이드입니다. 이전에 API를 구축한 적이 없는 초보자와 Django 기초 및 모범 사례에 대한 빠른 소개를 원하는 전문 프로그래머에게 적합합니다.

이것들은 최소한의 노력으로 기존 Django 웹사이트를 웹 API로 확장하는 데 도움이 되는 책의 필수 참고 사항과 코드 조각이며 처음부터 호스팅 및 API 문서에 이르기까지 모든 것을 다룹니다. Part II에서 Django Rest Framework의 기본 사항에 대해 논의할 것입니다. 의 시작하자!

Read Part I

Django Rest 프레임워크

Django는 웹페이지가 포함된 웹사이트를 만들고 Django REST Framework는 JSON을 반환하는 사용 가능한 HTTP 동사가 포함된 URL 끝점 모음인 웹 API를 만듭니다.

wsgi.py stands for web server gateway interface and helps Django serve the eventual web pages

데이터베이스 모델을 RESTful API로 변환하는 세 가지 주요 단계는 다음과 같습니다.

URL 경로에 대한 urls.py 파일

데이터를 JSON으로 변환하기 위한 serializers.py 파일

각 API 끝점에 논리를 적용하기 위한 views.py 파일

직렬 변환기

직렬 변환기는 데이터를 인터넷을 통해 사용하기 쉬운 형식(일반적으로 JSON)으로 변환하고 API 끝점에 표시됩니다.

메모:

• Always add a __str__ method to provide a human-readable name for each future model instance.
• Migration files are a fantastic way to debug applications and you should strive to create a migration file for each small change. If we had updated the models in two different apps and then run python manage.py makemigrations the resulting single migration file would contain data on both apps. That just makes debugging harder. Try to keep your migrations as small as possible.

CORS - 교차 출처 리소스 공유

클라이언트가 다른 도메인(mysite.com 대 yoursite.com) 또는 포트(localhost:3000 대 localhost:8000)에서 호스팅되는 API와 상호 작용할 때마다 잠재적인 보안 문제가 있습니다.

특히 CORS는 클라이언트가 도메인 간 요청을 허용해야 하는지 여부와 시기를 결정할 수 있도록 서버에 특정 HTTP 헤더를 포함하도록 요구합니다.

이것을 처리하는 가장 쉬운 방법(그리고 Django REST Framework에서 권장하는 방법)은 설정에 따라 적절한 HTTP 헤더를 자동으로 포함하는 미들웨어를 사용하는 것입니다.

우리는 django-cors-headers를 사용합니다:

corsheaders에 INSTALLED_APPS 추가

CorsMiddleware

에서 CommonMiddleWare 위에 MIDDLEWARE를 추가

생성 CORS_ORIGIN_WHITELIST

노트:

It’s very important that corsheaders.middleware.CorsMiddleware appears in the proper location. That is above django.middleware.common.CommonMiddleware in the MIDDLEWARE setting since middlewares are loaded top-to-bottom.

권한

Django REST Framework는 API를 보호하는 데 사용할 수 있는 몇 가지 즉시 사용 가능한 권한 설정과 함께 제공됩니다. 이는 프로젝트 수준, 보기 수준 또는 개별 모델 수준에서 적용할 수 있습니다.

탐색 가능한 API에 로그인 추가

This is such a common occurrence that Django REST Framework has a one-line setting to add login and log out directly to the browsable API itself.

Within the project-level urls.py file, add a new URL route that includes rest_framework.urls. Somewhat confusingly, the actual route specified can be anything
we want; what matters is that rest_framework.urls is included somewhere.

암호:

# blog_project/urls.py
from django.urls import include, path

urlpatterns = [
  ...
  path('api-auth/', include('rest_framework.urls')), # new
]

프로젝트 수준 권한

Django REST Framework는 다음을 포함하여 사용할 수 있는 여러 기본 제공 프로젝트 수준 권한 설정과 함께 제공됩니다.

AllowAny - 인증 여부에 관계없이 모든 사용자에게 전체 액세스 권한이 있습니다

.

IsAuthenticated - 인증된 등록된 사용자만 액세스할 수 있음

IsAdminUser - 관리자/수퍼유저만 액세스할 수 있습니다

.

IsAuthenticatedOrReadOnly - 권한이 없는 사용자는 모든 페이지를 볼 수 있지만 인증된 사용자만 쓰기, 편집 또는 삭제 권한을 가집니다

.

이 네 가지 설정 중 하나를 구현하려면 DEFAULT_PERMISSION_CLASSES 설정을 업데이트해야 합니다.

# blog_project/settings.py

REST_FRAMEWORK = {
  'DEFAULT_PERMISSION_CLASSES': [
      'rest_framework.permissions.IsAuthenticated', # new
  ]
}

메모:

• If a request contains HTTP verbs included in SAFE_METHODS – a tuple containing GET, OPTIONS, and HEAD –then it is a read-only request, and permission is granted.
• The generic views will only check the object-level permissions for views that retrieve a single model instance. If you require object-level filtering of list views–for a collection of instances–you’ll need to filter by overriding the initial queryset.

결론:

적절한 권한을 설정하는 것은 모든 API에서 매우 중요한 부분입니다. 일반적인 전략으로 인증된 사용자만 API를 볼 수 있도록 엄격한 프로젝트 수준 권한 정책을 설정하는 것이 좋습니다. 그런 다음 특정 API 엔드포인트에서 필요에 따라 보기 수준 또는 사용자 지정 권한에 더 쉽게 액세스할 수 있습니다.

Read Part III

GitHub 리포지토리에서 자세한 내용을 확인하세요.
https://github.com/PragatiVerma18/Django-For-APIs

이 노트를 재미있게 읽으셨다면 댓글로 여러분의 의견을 알려주세요. 저와 연결하고 싶다면 아래 링크를 따르십시오.

| GitHub | | StackOverflow