Flask 기본 개념

자! 기본적으로 web service는 response(Status line, Headers, Body)와 request(Start line, Headers, Body)의 관계로 끝난다! 그렇다면 Flask는?!

 

 

1.     Response

           - Response() 로 객체를 만든다

                     첫번째 인자는 표시할 문자열, 두번째 인자는 status line, 세번째 인자는 Header+Body

           - make_response() 로 보내야 큰 데이터를 보낼 때 서버도, 클라이언트도 가볍다

          

           -Response의 속성들

         

           - environ 은 플라스크의 환경 변수를 담고 있다

                     environ[‘REQUEST_METHOD’]처럼 부를 수 있다

           - start_response라는 함수를 인자로 받음

           - return make_response() 의 인자가 string이면 text html 로 나감 / function이면 text plain으로 나감

 

 

 

2.     Request

         

           - request event Handler는 request의 발생 시기에 일어날 event를 결정한다

                      before_request : 예전에 web filter 쓸 때 utf-8

                     after_request: request 후, response 일어나기 전에 실행

                     teardown_request: request 다 나가고 나서! (보통 에러 로그 남길 때 사용)

                     teardown_appcontext: application context가 다 끝나고 나서! (보통 에러 로그 남길 때 사용)

           -request의 parameter

                     1) args : 클라이언트의 요청 방식이 GET일 때 (request라는 우편의 편지 봉투에 써져 있는, 즉 url에 붙어 있을 때) args !

                     2) form : 클라이언트의 요청 방식이 POST일 때 (request라는 우편의 편지 봉투 내에 있는 내용일 때) form(=body) !

                     3) values : 요청 방식에 상관없이

          

           -request parameter를 이런 식으로 custom 할 수도 있다~

           - request 환경변수(environ)를 세팅해줘야 한다

           -xhr이란?

XMLHttpRequest(XHR) 객체는 서버와 상호작용하기 위하여 사용됩니다.

전체 페이지의 새로고침없이도 URL 로부터 데이터를 받아올 수 있습니다.

여기에서는 Ajax 이용해 json 보내기 위해

           - app.config.update( ) : app의 환경설정을 바꾼다

 

 

3.     Routing

-route() 데코레이터는 개발자가 정의한 함수와 URL 을 연결해준다

- app.route(‘/test’,methods=[‘POST’,’PUT’]) : POST랑 PUT일 때만 실행하라

- app.route(‘/test/<tid>’) : <tid> 이 부분이 변수가 되어서 바꿀 수 있다

- app.route(‘/test’, default={‘page’:’index’})

app.route(‘/test/<page>’)          <page>값이 안 들어왔을 때 default 값으로 ‘index’ 를 넘겨줄 수 있다

           - app.route(‘/test’,host=’abc.com’)

             app.route(‘/test’, redirect_to=’/new_test’) /new_test로 redirect해서 페이지 변경

 

-subdomain 이란!

           Ex) naver.com 에서 블로그 페이지는 blog.naver.com 이잖아. 이때 blog 부분이 subdomain!

 

 

 

4.     Global G

 

 

 

 

5.     Session (https://m.blog.naver.com/shino1025/221355012951)

           -session : 쿠키와 다르게 세션과 관련된 데이터는 서버에 저장된다. 서버에서 관리할 수 있다는 점에서 안전성이 좋아서 보통 로그인 관련으로 사용되고 있다. 플라스크에서 세션은 딕셔너리의 형태로 저장되며 키를 통해 해당 값을 불러올 수 있다.

           - app.secret_key와 같이 세션을 사용하기 위해서는 해당 값을 암호화하기 위한 Key 값을 코드에서 지정해주어야 한다

 

- session을 설정할 때, session[‘~~~~~’]=~~~~~~와 같은 형식으로 저장

- session을 가져올 땐, session.get(‘~~~~~~’)

- session을 없앨 땐, del session[‘~~~~’]

 

아래는 session을 이용한 로그인과 로그아웃 예제!!!!! 이거 보면 완전 이해 가능

 

6.     Cookies

(https://roksf0130.tistory.com/120)

(https://m.blog.naver.com/shino1025/221355012951)

- cookie 가 뭐하는 놈이냐

           : 쿠키는 텍스트 파일의 형태로 클라이언트 pc에 저장된다. 더 나은 방문자 경험과 사이트 통계를 위해 클라이언트 사용과 관련된 데이터를 저장하는 것이다. 쿠키는 클라이언트의 PC에 텍스트 파일 형태로 저장되는 것으로 일반적으로는 시간이 지나면 소멸한다. 보통 세션과 더불어 자동 로그인, 팝업 창에서 "오늘은 이 창을 더 이상 보지 않기" 등의 기능을 클라이언트에 저장해 놓기 위해 사용된다.

- cookie 의 생성 인자

           : request 객체에는 쿠키의 속성이 포함되어 있다. Flask에서 쿠키는 request 객체에 설정된다.

           : make_response() 함수를 사용하여 Response 객체를 가져온 후 set_cookies() 함수를 사용하여 쿠키를 저장한다 (make_response() 함수는 사용자에게 반환할 뷰 함수를 생성한 후, 그대로 묶어두는 역할을 한다.)

 

---

0. Flask

• Flask는 프레임워크로 "마이크로프레임워크"라고도 한다.
• 플라스크는 기본적인 기능부터 시작해서 확장 가능하도록 설계됐다.
• virtual environment를 생성하고 flask라는 폴더를 홈디렉토리에 만들었다.
• pip install flask로 flask를 설치하고 python > import flask 하여 문제없는지 확인한다.

 

1. 초기화

• 모든 플라스크 애플리케이션은 애플리케이션 인스턴스를 생성해야 한다.
• 웹 서버는 클라이언트로부터 수신한 모든 request를 이 오브젝트에서 처리하는데 이때 웹 서버 게이트웨이 인터페이스(WSGI)라는 프로토콜을 사용한다.
• 애플리케이션 인스턴스는 Flask 클래스의 오브젝트이며 다음과 같이 생성된다.

• Flask 클래스 생성자에 필요한 한 가지 인수는 메인 모듈의 이름이나 애플리케이션의 패키지 이름이다. 대부분 어플리케이션에서는 파이썬의 __name__ 변수가 적절한 값이다.

 

2. 라우트와 뷰 함수

• 웹브라우저같은 클라이언트는 웹 서버에 리퀘스트(request)를 전송하며 애플리케이션 인스턴스에 교대로 전송한다.
• 애플리케이션 인스턴스는 각 URL request 실행을 위해 어떤 코드가 필요한지 알아야 하며, 따라서 URL을 파이썬 함수에 mapping하는 기능이 필요하다.
• 이 URL과 이 URL을 처리하는 함수의 관련성을 라우트(route)라고 한다.
• 플라스크 앱(애플리케이션)에서 라우트를 정의하는 가장 손쉬운 방법은 앱인스턴스에서 app.route데코레이터를 사용하는 것이다.
• 데코레이터 함수를 라우트로 등록한다.
• 다음은 라우트가 데코레이터를 이용하여 어떻게 선언되는지 보여준다.

• http://www.example.com 웹 브라우저로  들어가면 서버에서 index()가 실행된다.
• 이 함수의 return 값은 응답(response) 이라고 하는데 클라이언트가 수신하는 값이다.
• 클라이언트가 웹 브라우저면 응답은 사용자가 보게되는 문서다.
• index() 와 같은 함수를 뷰 함수(view function)라고 한다.

 

• 우리가 사용하는 URL은 다음과 같이 되어 있다.
• http://www.facebook.com/
• 플라스크는 이러한 여러 가지 타입의 URL을 route 데코레이터에 있는 특별한 문법을 사용해서 지원한다.
• 다음 코드는 동적 이름 컴포넌트를 갖는 라우트를 정의한다.

• 꺽쇠 괄호로 닫혀 있는 부분이 동적 부분이며 정적 부분과 매칭되는 URL이 이 라우트에 매핑된다.
• 뷰 함수가 실행되면 플라스크는 동적 컴포넌트를 인수로 전송한다.
• 뷰 함수의 이전 예제에서 이 인수는 응답으로 'Hello World'를 생성하였다.
• 라우트에 있는 동적 컴포넌트는 기본적으로 문자열이지만 타입에 의해 정의될 수도 있다.
• 예를 들어 라우트 /user/<int:id> 는 id 동적 세그먼트에서 정수값을 찾는 URL에만 매칭된다.
• 플라스크는 라우트에 대해 int, float, path를 지원한다.

 

3. 서버 시작

• 애플리케이션 인스턴스는 run 메소드를 갖고 있는데 이 메소드는 플라스크의 통합 개발 웹 서버를 실행한다.

• __name == '__main__' 은 스크립트가 직접 실행될 때만 개발 웹 서버가 실행된다는 것을 알려준다.
• 스크립트가 다른 스크립트에 의해 임포트 되며 부모 스크립트는 다른 서버를 실행할 수 있으며 따라서 app.run() 호출은 건너뛰게 된다.
• 서버가 실행되고 나면 선버는 루프를 진행하며 리퀘스트를 기다리고 리퀘스트를 서비스하게 된다.
• Ctrl+C로 중지 가능하다.

• app.run()에 주어진 여러가지 옵션 인수를 사용하여 웹 서버의 오퍼레이션 모드를 설정할 수 있다.
• 개발 과정에서 이러한 기능은 디버그 모드를 사용할 수 있도록 하기 때문에 편리하며 디버거(debugger)와 리로더(reloader)를 활성화할 수도 있다. 이것은 debug인수를 True로 설정하면 된다.

 

4. 완벽한 애플리케이션

• 정적 라우트를 사용한 플라스크 애플리케이션

• 동적 라우트를 사용한 플라스크 애플리케이션

 

5. 리퀘스트-응답 사이클

애플리케이션과 리퀘스트 컨텍스트

• 플라스크가 클라이언트에서 리퀘스트를 수신하면 이 리퀘스트를 처리하기 위해 뷰 함수에서는 사용 가능한 몇 개의 오브젝트를 생성해야 한다.
• 좋은 예는 Request Object인데 이 오브젝트는 클라이언트에 의해 송신된 HTTP리퀘스트를 캡슐화한다.
• 플라스크에서 뷰 함수가 Request Object를 액세스할 수 있도록 하는 확실한 방법은 인수로서 리퀘스트 오브젝트를 전송하는 것이다. 그러나 이 방법은 애플리케이션의 모든 뷰 함수가 각각 여분의 인수를 갖도록 요구한다.
• 리퀘스트 오브젝트만이 뷰 함수가 리퀘스트를 액세스해야 하는 오브젝트가 아니라는 사실을 고려해 보면 좀 더 복잡해진다.
• 뷰 함수가 필요하지도 않은 너무 많은 인수를 갖는 것을 피하기 위해 플라스크는 컨텍스트(Context)를 사용하여 임시적으로 오브젝트를 글로벌하게 액세스하도록 한다.

[대충 정보통신 용어로서의 컨텍스트는 호출, 응답 간의 환경 정보라고 정의할 수 있을 것 같다. 즉, 누가 무엇을 어떤 의도를 가지고 언제 행위를 하였는지에 대한 정보를 통칭하여 컨텍스트라고 하는 듯 하다.]

• 뷰 함수는 다음과 같이 작성할 수 있다.

• 스레드들이 동시에 서로 다른 클라이언트가 요청하는 서로 다른 리퀘스트를 처리하는 멀티스레드 서버를 고려한다면 실제로 request는 전역변수가 될 수는 없다.
• 따라서 각 스레드는 request에 있는 다른 오브젝트를 처리하게 된다.
• 컨텍스트를 사용하면 플라스크는 다른 스레드의 개입 없이 임의의 변수들이 전역적으로 스레드에 액세스될 수 있도록 해 준다.
• 플라스크에는 두 가지 컨텍스트가 있다. 하나는 애플리케이션 컨텍스트이고 다른 하나는 리퀘스트 컨텍스트이다.

[어플리케이션 컨텍스트

 

- current_app : 활성화된 어플리케이션을 위한 인스턴스

- g : 리퀘스트를 처리하는 동안 어플리케이션이 임시 스토리지를 사용할 수 있는 오브젝트, 이 변수는 각 리퀘스트에 따라 리셋된다.

 

리퀘스트 컨텍스트

- request : 클라이언트에 의해 송신된 HTTP 리퀘스트의 컨텐츠를 캡슐화하는 오브젝트

- session : 사용자 세션이며, 어플리케이션이 리퀘스트 사이의 "remembered" 인 값들을 저장하는 데 사용하는 딕셔너리]

 

리퀘스트 디스패치

• 애플리케이션의 클라이언트에서 리퀘스트를 수신하면, 그것을 서비스하기 위해 실행할 뷰 함수가 무엇인지 검색해야 한다.
• 이를 위해 플라스크는 애플리케이션 URL 맵에서 리퀘스트에 주어진 URL을 검토하고 그것을 처리할 뷰 함수에 URL의 매핑을 포함하고 있는지 찾는다.
• 플라스크는 이 맵을 app.route데코레이터나 데코레이터를 사용하지 않은 버전인 app.add_url_rule()를 사용하여 빌드한다.

• UR맵에 있는 HEAD, GET, OPTIONS 항목은 라우트에 의해 처리되는 리퀘스트 메소드(Reuest method)다.
• 플라스크는 각 라우트에 대한 메소드를 부착(attach)하며, 따라서 같은 URL에 서로 다른 리퀘스트 메소드라고 하더라도 다른 뷰함수에 의해 처리된다.

리퀘스트 후크

• 때로는 각각의 리퀘스트를 처리하기 전후에 코드를 실행하는 것이 유용하다.
• 예를 들어, 각 리퀘스트의 시작 부분에서 Database Connection을 해야하는 경우, 리퀘스트를 생성하는 사용자를 인증해야 하는 경우 등이 있다.
• 모든 뷰 함수에서 이러한 작업을 처리하는 코드를 중복하여 생성하는 대신에 플라스크에서는 옵션을 제공하여 공통 함수를 등록하고 리퀘스트가 뷰 함수에 디스패치되는 전후에 실행되도록 한다.
• 리퀘스트 후크는 데코레이터를 사용하여 구현하며 플라스크에서 제공하는 네 개의 후크는 다음과 같다.
• before_first_request, before_request, after_request, teardown_request
• 리퀘스트 후크 함수와 뷰 함수 사이에 데이터를 공유하기 위한 공통 패턴은 g 컨텍스트 전역 변수를 사용하는 것이다.
• 예를 들어, before_request 핸들러는 데이터베이스에서 사용자에 대한 로그를 로드하여 g.user에 저장한다.
• 이후에 뷰 함수가 호출되었을 때 그 저장된 곳에서 사용자를 액세스하게 된다.

응답

• 플라스크가 뷰 함수를 호출할 때 리퀘스트에 대한 응답(response)으로 값을 리턴하게 된다.
• 대부분의 경우 응답은 간단한 문자열이며 HTML페이지로 클라이언트에 전송된다.
• 그러나 HTTP 프로토콜은 리퀘스트에 대한 응답으로 문자열 이상의 것을 요구한다.
• HTTP 응답의 가장 중요한 부분은 상태 코드(Status Code)이며 플라스크에서는 기본적으로 200으로 설정한다.
• 이 코드는 리퀘스트가 올바르게 처리되었는지 알려준다.
• 뷰 함수가 다른 상태 코드를 갖는 응답을 필요로 할 때, 응답 텍스트 이후에 두 번째 리턴값으로 뉴메릭(numeric) 코드를 추가할 수 있다.
• 예를 들어 다음의 뷰 함수는 400 상태 코드를 리턴하는데 이는 잘못된 리퀘스트 에러 코드이다.

• 플라스크 뷰 함수는 하나, 두 개 혹은 세 개의 값을 튜플(tuple)로 리턴하는 대신 Repsonse 오브젝트를 리턴하는 옵션을 갖는다.
• make_response()함수는 한 개, 두 개 혹은 세 개의 인수를 가지는데 이는 뷰 함수에서 리턴되는 것과 같은 값이며 Response 오브젝트를 리턴한다.