예를들어 ID가 402인 사용자 정보를 가져오고 싶은 경우 GET 방식을 통해 데이터를 전송할 수 있다.
localhost:8080/users/402
와 같이 전송할 수 있는데 이런 방식을 Path Parameter라고 한다.
조금 더 우리에게 익숙한 방식으로는 /users?id=402
가 있는데 이런 방식을 Query Parameter방식 혹은 Query String이라고 부른다. API 뒤에 입력 데이터를 함께 제공하는 방식으로 사용하며 Query String은 Key, Value의 쌍으로 이루어지며 &
로 연결하여 여러 데이터를 넘길 수 있다.
ex) https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=광진구
Query 적용해보기
Path vs. Query
언제 어떤방식을 사용해야 하는지는 상황마다 다르다.
만약 어떤 Resource가 있는지 식별하고 싶은 경우 해당 Resource가 존재하지 않는다면 Path 방식은 경로에 존재하는 내용이 없으므로 404 Error를 발생하고 Query는 빈 리스트가 나오기 때문에 추가로 Error Handling이 필요하다.
Resource를 식별해야 하는 경우는 Path, 정렬 및 필터링을 해야하는 경우 Query가 적합하다.
특정 파라미터는 Optional(선택적)으로 하고 싶은 경우 사용한다.
typing 모듈의 Optional을 사용하여 적용할 수 있다.
클라이언트에서 API에 데이터를 보낼 때 Request Body를 사용하며 항상 데이터가 포함되어야 하는 것은 아니다. 하지만 Request Body에 데이터를 보내고 싶다면 POST 방식을 사용하여 전달해야 한다.
(참고) GET은 URL, Request Header, POST는 Request Body
Body에는 Content-Type이라는 Header필드가 존재하고 어떤 데이터 타입인지 명시해야 한다.
직접 curl로 POST를 수행할 수 있지만 지난 시간에 배운 docs를 활용해보자.
docs에 들어가면 기본적인 docs를 확인할 수 있다.
POST버튼을 클릭하면 curl명령어를 확인할 수 있으며 Try it out을 클릭하면 실제로 POST를 실행해볼 수 있다.
Request와 마찬가지로 Response Body도 필요하다.
FastAPI에서는 Decorator의 response_model 인자로 주입할 수 있다.
마찬가지로 Swagger에서 POST를 날려 결과를 확인하면 아래와 같다.
Form(입력)형태로 데이터를 받고 싶은 경우 python-multipart
를 설치해야 한다.
pip install python-multipart
프론트도 간단히 만들기 위해 Jinja2를 설치 한다.
pip install Jinja2
Form 클래스를 사용하면 Request의 Form Data에서 값을 가져온다.
URL로 logins에 접근하면 Method Not Allowed가 발생하는데 url로 접근하는건 보통 GET으로 요청되기 때문이다.
프론트쪽과 위의 문제를 해결하기 위해 코드를 리팩토링 한다.
제출을 누르게 되면 post요청이 실행되고 username을 리턴하는 것을 확인할 수 있다.
FastAPI에서 Class 사용할 때 보이던 라이브러리이다.
Data Validation이나 Settings Management에 사용할 수 있으며 Type Hint를 런타임에서 강제하여 안전하게 데이터 핸들링이 가능하다.
파이썬의 기본 타입(String, Int 등) + List, Dict, Tuple에 대한 Validation을 지원하며 기존 Validation 라이브러리 보다 빠르다는 장점이 있다. 더 나아가 Config를 효과적으로 관리하도록 도와주며 머신러닝 Feature Data Validation으로도 활용할 수 있다.
조건 | 설명 |
---|---|
1 | 올바른 url 입력(url) |
2 | 1-10사이의 정수 입력(rate) |
3 | 올바른 폴더 이름 입력(target_dir |
위와 같은 조건이 있을때 사용할 수 있는 방법은 아래와 같다.
Dataclass는 init을 따로 작성할 필요가 없어지며 post_init()(따로 호출하지 않아도 생성 시점에 진행)과 같은 magic method를 사용할 수 있다. 하지만 여전히 validate method를 따로 만들어서 검증을 해야한다.
Pydantic에는 다양한 함수들을 제공하여 쉽게 검증이 가능하다.
이 외에도 db, enum 등 다양한 Validation이 만들어져 있다.
어디서 에러가 발생했는지, location, type, message 등을 알려준다.
Pydantic은 Config를 체계적으로 관리할 방법을 제공한다. 기존에 다른 라이브러리들은 어떤식으로 관리하는지 알아보자.
종종 설정을 상수로 코드에 저장하는 경우를 볼 수 있는데 이것은 Twelve-Factor를 위반하는 행위이다. Televe-Factor는 설정을 코드에서 엄격하게 분리하는 것을 요구하며 환경 변수에 저장하도록 권고하고 있다.
환경 변수는 코드 변경 없이 쉽게 배포 때마다 변경할 수 있으며 SaaS(Software as a Service)를 만들기 위한 방법론에서는 환경 설정은 애플리케이션 코드에서 분리되어 관리되어야 한다고 나와있다.
.init
, .yaml
파일 등으로 config 관리yaml으로 환경 설정을 관리할 경우 쉽게 설정할 수 있지만 결국 코드로 하드코딩하는 형태로 볼 수 있다. 때문에 변경 사항이 생길때 유연하게 적용하기 힘들 수 있다.
config.py
Config 클래스에서 yaml. ini 파일을 불러와 python class 필드로 주입하는 과정을 구현한 것으로 Config를 상속한 클래스에서는 Config 클래스의 정보를 오버라이딩해서 사용한다. 하지만 해당 파일의 데이터가 정상적인지 체크하거나(Validation) 환경 변수로 부터 해당 필드를 오버라이딩 하려면 코드량이 늘어난다.
pydantic에서 제공하는 BaseSettings를 사용하여 클래스에서 Type Hind로 주입된 설정 데이터를 검증할 수 있다. Field 클래스의 env 인자로 환경 변수로 부터 해당 필드를 오버라이딩 할 수 있으며 추가적인 파일을 만들지 않고 .env 파일들을 환경별로 만들어 두거나 실행 환경에서 유연하게 오버라이딩 할 수 있다.
위의 세 방법 모두 틀린 방법은 아니므로 현업에서 사용하는 방식을 따라가되 상황에 따라 여러가지 방식을 시도해볼 필요가 있다.