cursor = user_db.cursor() sql= " select * from user_info"
cursor.execute(sql) print(cursor.fetchall())
4) request 에서 조건값 가져오기
http://localhost:80/api/users/1234
ㅁ Rest_api 서버 코드 수정
@api.route('/api/users/<int:id>') -- id라는 변수를 만들어 int 값 저장 class HelloWorld(Resource): def get(self,id): -- 멤버 변수 파라미터로 id 설정 return {"id": id, -- id 변수값 "name": "kim"}
5) 가져온 조건값을 DB에 입력하여, 리턴해주도록 수정
@api.route('/api/users/<int:id>') class HelloWorld(Resource): def get(self,id): cursor = user_db.cursor() sql = " select * from user_info where id= " + str(id) cursor.execute(sql) data=cursor.fetchall() return {"id": data[0][0], "name": data[0][1]}
=> 설치중에 커넥션 에러 발생. security.ubuntu는 접근하나, archive.ubuntu 에는 접근 못하는 것으로 추정
Get:116 http://security.ubuntu.com/ubuntu bionic-updates/main amd64 python3-xdg all 0.25-4ubuntu1.1 [31.3 kB] Fetched 105 MB in 1min 6s (1586 kB/s) E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/i/isl/libisl19_0.19-1_amd64.deb Could not connect to XXXXX
=> ubuntu repository를 변경하자. ( mirror.kakao.com )
vi /etc/apt/sources.list => 편집창에서 :%s/archive.ubuntu.com/mirror.kakao.com
apt-get update apt-get install python3-pip
- Flask 다운로드
Flask : Micro web framework로 직역하면 가볍게 사용할수 있는 웹 프레임워크다.
간단한 rest api 서버 혹은 Web 서버 구성시에 사용한다.
pip3 install Flask
이제는 익숙한 프록시, SSL 오류.
1) 구글링하니, trusted host 옵션을 주라고 한다.
=> 동일 에러
pip3 install --trusted-host pypi.python.org flask
2) 블로그에 프록시 컨피그 적용 후, 수행 가이드
pip3 install --proxy your_proxy_path Flask
=> SSL 문제로 URL 접속 불가 이슈
==>VM 환경이 아닌, 로컬 환경에서는 인터넷 접속 이상없음
1,2 옵션을 동시에 주면된다.
- 프록시를 통해 패키지 Install
- SSL 없이, python host에 대해서는 신뢰
-> Flask 및 dependency 패키지 다운로드 성공
같은 방법으로 Flask-restx 도 설치해준다.
- Rest Server Code 작성
from flask import Flask from flask_restx import Api, Resource
app = Flask(__name__) api = Api(app)
@api.route('/api/users') # /api/user 에 클래스 매핑 class HelloWorld(Resource): def get(self): return {"id": 123, "name": "kim"}
if __name__ == "__main__": app.run(debug=True, host='0.0.0.0', port=80)
sudo docker run -p 80:80 sk007001/rest_api:python python3 /python/rest_api.py [ -p ] : 호스트의 80 포트로 오는 요청을 해당 컨테이너 80포트로 연결 [ python3 /python/rest_api.py ] : 위에 만들어둔 rest api 코드 실행
- RestClient 를 사용하여, 리퀘스트를 던져보자
※ 보완할 점
- 컨테이너 수행시 명령어가 너무길다.
이미지에 수행될 명령어를 미리 지정하여, 컨테이너만 수행해도 rest_api 서비스가 올라가도록 변경해볼 것
- DB 연결후, /api/users 뒤에 파라미터값에 따라 다른 값을 리턴하는 로직 구현
- 신규 데이터 Insert 불가 - Full Table scan시에 HWM까지 탐색하므로, 불필요한 작업 발생
Truncate 하면 ( 테이블 구조만 남기고, 데이터는 모두 삭제 )
TBS 확보 및 HWM 위치를 조절할 수 있으나
일부 데이터만 삭제하려는 위의 케이스에는 맞지않다.
해당 케이스에는 비워진 공간만큼 재구성하는 리오그 ( Reorganization ) 작업이 필요한 것이다.
Reorg 방법
1) ALTER TABLE MOVE
- 속도가 빠르다
- 데이터 용량만큼의 TBS 공간 추가로 필요
- TBS 오프라인 필요
1) 임시 테이블 스페이스 생성 CREATE TABLESPACE '임시TBS명' DATAFILE 'DB파일_PATH' SIZE 1G;
2) 속도를 위해 해당 테이블 Nologging 모드 ALTER TABLE 테이블이름 NOLOGGING;
3) 데이터 삭제후, 대상 테이블 임시 테이블스페이스로 이동 ALTER TABLE '테이블명' MOVE TABLESPACE '임시TBS명';
4) 기존 테이블스페이스로 원복 ALTER TABLE '테이블명' MOVE TABLESPACE '기존TBS명';
5) 인덱스 상태 확인 SELECT TABLE_NAME, INDEX_NAME, STATUS FROM DBA_INDEXES WHERE TABLE_NAME = '테이블명'; -> 지워진 인덱스의 경우, 실제 delete가 아닌 Unusable 마킹만 되어있다. 계속 두면 segment가 실 데이터양보다 커질 수 있으니, rebulid 명령어로 정리해주자.
REST 아키텍쳐를 따르는 시스템을 Restful, API 통신을 Rest Api 라고도 한다.
특징 6가지
1) Uniform (유니폼 인터페이스) 2) Stateless (무상태성) 3) Cacheable (캐시 가능) 4) Self-descriptiveness (자체 표현 구조) 5) Client - Server 구조 6) 계층형 구조
1) 유니폼 인터페이스
URI로 지정된 리소스에 대해, 통일된 인터페이스로 수행되는 것을 의미한다.
나같은 경우는 통일된 (Uniform) 인터페이스라는 표현의 이해가 어려웠는데,
클라이언트의 환경 ( 플랫폼 / 프로그래밍 언어 )에 종속되지 않는 느슨한 결합 ( Loosly Coupling ) 아키텍쳐가 더 이해하기 쉬웠다.
2) 무 상태성
서버단에서 상태 정보(컨텍스트)를 저장하지 않음을 의미한다.
세션이나 쿠키같은 정보를 저장하지않고, Request에 대해 들어온 요청대로 수행하기만한다.
요청에 대해 History 고려 및 정보 저장이 필요없으므로, 구현이 간단해진다는 장점이 있다.
3) 캐시 가능
HTTP 메소드를 사용하기에, 기존 캐시 기능을 그대로 사용할 수 있다.
Last-Modified 혹은 E-tag를 사용하여 데이터 갱신유무를 파악하고, 변화가 없으면 클라이언트의 자체 캐시값을 활용한다
※ HTTP Cash 프로세스 - 리퀘스트 헤더에 Last Modified를 포함하거나, E-tag를 사용하여 보낸다 ( E-tag가 우선됨 )
1) Last Modified 값을 If-modified-Since 헤더에 포함시켜, 서버측의 시간과 비교한다. 2) E-tag 값을 If-None-Match 에 포함시켜, 서버측의 값과 비교한다 => 값이 같다면 304 Not Modified 리턴코드를 응답하고, 클라이언트는 가지고있는 캐시값을 사용한다.
4) 자체 표현 구조
리퀘스트만 보고도 무슨 내용인지 직관적으로 파악이 가능해야한다.
예를들어, GET http://localhost/customer/123 라는 리퀘스트가 있다고 하자.
단번에 회원중에 키값(회원ID)가 123인 사람을 조회하는 GET 메소드 라는것을 알 수 있다.
5) 클라이언트 - 서버구조
API를 통해 요청하고, 인증이나 컨텍스트 정보를 직접 관리하는 Client 와
접근가능하도록 API를 제공하는 Server 역할로 나누어 독립적인 개발이 가능하도록 한다.
6. 계층형 구조
클라이언트 입장에서는 Api를 통해 서버로 요청하지만,
서버 내부적으로 다양한 계층을 지닐수 있다.
스위치 , WEB 서버등을 통해 사용자 인증, SSL, 로드밸런싱 등을 구현할 수 있으며
Apache Reverse Proxy나 HA Proxy 등을 통해 Host 분리없이 구현할 수 있다.
구현 가이드
1. 자원에 대한 행위는 CRUD를 사용한다.
Create - [HTTP Post] 해당 리소스를 생성한다. Read - [HTTP Get] 해당 리소스를 조회한다. Update - [HTTP Put] 해당 리소스를 수정한다. Delete - [HTTP DELETE] 해당 리소스를 삭제한다.
2. URI는 정보를 표현해야한다. ( 명사형 )
1번과도 연관된 내용이다.
동사는 CRUD로 제한하고, 나머지 자원에 대한 정보는 모두 명사로 표시한다.
3. /로 리소스 계층을 식별한다
ex ) GET http://localhost/customer/123
마지막에 /는 혼동을 줄수있기에 넣지 않는다.
4. 모든 경로에는 소문자를 사용한다.
대소문자에 따라 리소스를 다르게 인식하기 때문에, 대문자는 사용하지 않는다.
5. 하이픈 ( - )을 통한 가독성
언더바 ( _ )는 환경에 따라 보기 힘들수도 있기때문에,
URI 내의 가독성을 높이고 싶으면 하이픈을 사용한다.
ex) GET http://localhost/vip-customer/123 ( O ) GET http://localhost/vip_customer/123 ( X )
※ HTTP Response Code
Rest Api를 통해 리퀘스트에 단순 응답만 하는것이 아닌
다양한 Response Code 들을 통해, 처리결과를 좀더 정확하게 회신주어야한다.
대표적인 값은
2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다 - 200 : 클라이언트 요청을 정상적으로 수행함 - 201 : 서버가 요청한 리소스 생성작업을 성공함
3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다 - 301 : 사용자가 요청한 페이지에 대해 URI가 변경되었다.
4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다 - 400 : 사용자가 요청이 어떤것인지 인식하지 못했을 때 - 401 : 사용자의 권한이 부족하거나 인증이 완료되지 않음 - 403 : 금지된 리소스에 사용자가 접근할 때 - 404 : 존재하지 않는 리소스를 요청했을 때 - 405 : 잘못된 메소드로 서버에 요청했을 때
5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다 - 500 : 내부 서버오류로 인해 요청 수행 불가
