[Django 공식문서 번역] HTTP Requests - 1. URL dispatcher

이 글은 본인이 공부를 목적으로 공식문서를 읽으며 정리/번역한 글로서 오역이 있을 수 있을 수 있습니다. 또한 본인이 이미 알고 있거나 불필요하다 느끼는 내용들은 누락될 수 있습니다.

어플리케이션의 URL을 디자인하기 위해서는 URLconf(URL configuration)라는 파이썬 모듈을 만들어야된다. 이 모듈을 파이썬으로 작성되었으며 URL 경로와 파이썬 함수간 매핑을 해준다.

장고가 Request를 처리하는 방식:

1. 장고는 사용해야될 루트 URLconf 모듈을 정한다. 기본적으로 이는 setting에 명시된 ROOT_URLCONF의 값을 사용하지만 만약 HttpRequest 객체에 urlconf 속성이 있다면 속성에서 명시된 값을 사용한다.

2. 장고는 파이썬 모듈을 로드하고 urlpatterns라는 변수를 찾는다. 이는 django.urls.path()나 django.urls.re_path()인스턴스로 구성되어야 한다.

3. 장고는 URL pattern을 하나씩 순서대로 검사하다가 요청된 URL과 매치되는 첫번째 패턴에서 멈춘다.

4. URL pattern과 매치가 됐다면, 장고는 해당 view를 임포트하고 호출한다. 해당 view는 다음 인자들을 전달 받는다.
    - HttpRequest 객체
    - 만약 매치된 URL pattern이 named group을 포함하고 있지 않다면, 정규표현식에서 매치된 값들이 positional argument로 전달된다
    - keyword argument는 경로 표현식의 named parts로 이루어져 있으며, django.urls.path()나 django.urls.re_path()의 kwargs argument로 덮어씌워진다.

5. 만약 매칭되는 URL pattern을 찾지 못했거나 exception이 발생했다면, 장고는 error-handling view를 호출한다.


Path Converters

str: 비어있거나 '/'를 제외한 string을 매칭한다.
int: 0이나 양의 정수를 매칭한다.
slug: ASCII문자들이나 숫자들, 그리고 '-'와 '_'까지 매칭한다.
uuid: UUID를 매칭한다. 무조건 dash가 포함되어야하며 문자들은 소문자여야된다.
path: 비어있지않은 string을 매칭하며 '/'까지 포함될 수 있다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[Django REST Framework] create() vs perform_create()

Django REST Framework의 ModelViewSet과 create() 관련 찾아보고 공부한 내용을 정리해보려고 한다. 기본적으로 ModelViewSet은 GenericAPIView라는 클래스를 상속받기 때문에 .list(), .create()  .list(), .create() 등을 기본으로 내장하고 있다. 따라서 이 중에서 기본 내장되어 있는 메소드 중 동작을 변경하고 싶은 것들만 overriding해서 수정하면 된다. 그리고 ModelViewSet은 GenericAPIView를 상속받고 있기 때문에 최소한 queryset와 serializer_class는 세팅해주어야 한다. from rest_framework import status from rest_framework.response import Response def create(self, request, *args, **kwargs): serializer = self.get_serializer(data=request.data) serializer.is_valid(raise_exception=True) self.perform_create(serializer) headers = self.get_success_headers(serializer.data) return Response(serializer.data, status=status.HTTP_201_CREATED, headers=headers) def perform_create(self, serializer): serializer.save() 위의 코드를 보면 이해가 조금 더 쉬울 것 같다. perform_create()은 create()의 동작 중 일부분을 overriding한다고 생각하면 되는데, serializer.save()가 호출될 때 perform_create()가 호출된다고 생각하면 된다. 위의 경우 명시적으로 perform_create()를 호출했지...
자세한 내용 보기

[웹 보안] CORS란?

원문:  https://dev.to/nicolus/what-you-should-know-about-cors-48d6 CORS는 Cross-Origin Resource Sharing의 줄임말이다.  처음배우는 사람들에게는 CORS가 무엇때문에 사용되는지 헷갈릴때가 많다. 첫째로, CORS는 보안을 강화하기 위한 수단이 아니다. 사실 그의 정반대이다. CORS는 Same Origin Policy(Browser의 정책중 하나로 document나 script가 다른 domain과 교신하는 것을 막는다)를 피하기위함이다. Same Origin Policy는 하나의 도메인에서 다른 도메인으로 요청하는 것을 막는다. 이렇게 하면 악성 웹사이트들이 다른 웹사이트들에게 요청보내는 것을 막을 수 있다. 이 정책은 브라우저에 적용되어 있기때문에 서버에서 보낸 요청이나 다른 HTTP 클라이언트(cURL / POSTman 등)에게는 적용되지 않는다. 서버는 이 요청들을 신뢰할 수 있는 도메인에서 보낸 요청이라고 생각하고 처리할 수 밖에 없다.  SOP(Same Origin Policy)는 공격자가 요청을 보내는 것을 막기 위한 수단이 아니다(공격자들은 브라우저를 사용하지 않을 것이다..). SOP는 단지 정당한 사용자들이 본인도 모르게 보내는 요청들을 걸러주는 역할을 한다. 그래서 CORS는 일반적으로 SOP에 의해 막힐요청을 화이트리스트에 등록해 허용해주는 역할을 한다(예를 들자면 front-end app이 API에 요청을 보내는 것)
자세한 내용 보기

3. GRAPHQL FRAGMENTS

# Why do we need Fragments? Fragments are used to reduce redundancy. You can think of it as something like struct in C. For exmaple, ``` query {   Lift(id: "jazz-cat") {     name     status     capacity     night     elevationGain     trailAccess {       name       difficulty     } }   Trail(id: "river-run"){     name     difficulty     accessedByLifts {       name       status       capacity       night       elevationGain ...
자세한 내용 보기