1 FastAPI 알아보기

00 FastAPI 설치 시 주의사항

• 도중에 FastAPI 설치 시 pip install fastapi == 0.97.0 명령어 사용 권장
  • 이유
    • 강의 제작 시점에는 pydantic v2 공식 버전이 출시되지 않아 본 강좌는 pydantic v1을 기준으로 만들어짐
    • FastAPI 최신 버전 설치 시 FastAPI가 pydantic v2를 사용하게 됨
    • 만약 pydantic v2를 사용하고 싶은 분들은 아래 문서 참고하여 migration 진행 권장
      • V2 migration: https://docs.pydantic.dev/latest/migration/ 
  • FastAPI 0.100.0 버전 이상부터 pydantic v2 공식 지원함
• 최종 완성본 프로젝트는 아래의 주소에 공개되어 있음
  • https://github.com/qu3vipon/inflearn-todos

01 FastAPI 소개

1. FastAPI란

1) GitHub Star History

• 최근 (2018년 말)에 만들어진 파이썬 웹 프레임워크로 단기간 내에 많은 인기를 얻음
• 참조: https://star-history.com/#tiangolo/fastapi&Date

2) 사용하는 기업

• Microsoft, Uber, Netflix와 같은 글로벌 테크 기업에서 FastAPI 사용
• 참조: https://fastapi.tiangoo.com/#opinions

3) Django와 비교

	Django + DRF	FastAPI
기능	Battery Included	경량 Framework
확장성	제한적	자유로움
	이유: - Django는 일반적으로 DRF - Django REST Framework와 같이 사용됨 - DRF 활용하여 MVC 패턴 구현 가능 - 내장된 serializer 활용하여 데이터 validation과 같은 기능 구현 가능 - 그러나 DRF 사용시 프레임워크에 강하게 결합되기에 다른 프레임워크로 변환 또는 다른 디자인 패턴을 적용하기에는 제한적임	이유: - 요구에 맞는 디자인 패턴 적용하기에 용이
성능		Django보다 우수
		이유: - 비동기 처리를 프레임워크 자체적으로 지원하기에 Django보다 성능이 우수 - 가벼운 framework도 성능 향상을 도움
사용 예	Admin과 같이 기본적으로 제공되는 기능을 활용하여 빠르게 프로토타이핑하는 프로젝트에 적합	기능이 단순한 가변 웹 서버를 띄우거나 직접 디자인 패턴을 적용해서 확장 가능한 앱 프로젝트에 적합

 

02 FastAPI 장점

1. 성능

• Python 프레임워크 중 가장 빠르다고 알려져 있음

2. 직관적인 디자인

• path, query, body, response, dependency에 대한 처리가 쉬움

3. Type Hints

• 최신 프레임워크로서 프레임워크 내에서 Type Hints 지원하여 Pydantic을 통한 안정적인 타입 처리와 Data Validation 및 IDE Support를 활용한 빠른 개발 가능

4. 비동기 처리

• AsyncIO나 Background Task에 대한 처리가 매우 쉽고 간단하여 다른 비동기 라이브러리 (예: celery) 없이도 간단한 비동기 작업 처리 가능

5. 자동 API 문서 생성

• 웹개발 시 클라이언트 사용자를 위해 API 문서를 적은 일이 매우 귀찮고 번거로우나 FastAPI 사용 시 OpenAPI 스펙에 맞는 API 문서를 자동으로 생성해줌
• 문서 작성의 번거로움 감소, Type Hints를 통해 실제 코드가 문서에 그대로 반영되기에 문서 누락 실수 방지
• 기본으로 사용 가능한 SwaggerUI 사용 시 웹 서버에 실제로 요청을 보내보기 가능

03 Client-Server 모델

1.Client-Server 모델이란

• 최신 웹 개발에서는 Client-Server 모델 사용
• 정의: 서비스를 사용하는 요청자(Client)와 서비스를 제공하는 제공자(Server)를 분리하여 역할과 책임을 각각 관리하는 구조를 가진 모델
  • Client: 서비스 요청자
  • Server: 서비스 제공자

2. Client-Server 모델의 장점

1) 확장 가능성

• Client와 Server 분리 시 구조적인 확장이 용이해짐. 즉, 하나의 Server에서 다수의 Client 대응 가능

2) 관심사의 분리

• Client와 Server의 역할이 명확히 분리되어 있어 각각 해결해야 하는 문제에 집중 가능
• 일반적으로 Client의 컴퓨팅 능력이 낮기에 무거운 연산 처리는 고사양의 Server에서 대신하여 성능에 대한 최적화 가능
• 개인정보와 같은 보안이 중요한 데이터는 권한이 부여된 사용자만 Server에 접근이 가능하도록 만들어 안전하게 데이터 관리 가능

3. Web 서비스

HTTP 요청	Client → (Network) → Server	<API>
HTTP 응답	Client ←  (Network) ← Server

• Web 서비스에서 HTTP 요청이란 Client가 네트워크를 통해 Server로 데이터나 명령을 요청하는 것
• Web 서비스에서 HTTP 응답이란 Server가 Client 요펑에 대한 결과를 돌려주는 것
• Client와 Server는 올바르게 데이터를 주고받기 위해 사전에 협의된 API라는 형태로 통신함

04 API

1. API란

• 'Application Programming Interface'의 약자 
• Server의 기능을 Client가 사용할 수 있도록 제공하는 인터페이스 (interface)

2. Interface란

• 컴퓨터 프로그래밍에서 인터페이스는 두 시스템 간에 신호를 주고 받는 접점을 의미
• 예) 에어컨(Server)과 리모컨(api)
  
  • 에어컨 (Server)
    • 내부 기능: 실내 온도 감지, 실외기 조작
    • 외부에서 제어하는 방법: 리모컨으로 전원 on/off, 온도 조절, 바람 세기 조절
  • 리모컨 (API)
    • 에어컨의 기능을 외부에서 사용할 수 있게 여러 버튼 (전원 on/off, 온도 조절, 바람 세기 조절) 제공
    • 사용자 → 버튼 (물리 신호) 누름 → 전기 신호로 변환 → 장비
  • 설명:
    • 사용자(Client)가 에어컨(Server)을 키기(Server의 기능) 위해 리모컨(api)의 전원 버튼(특정한 api)을 누름
    • 리모컨의 전원 버튼을 누르는 물리적 신호가 전기 신호로 변환되어 에어컨을 동작시킴
    • 에어컨을 내부적으로 보면 실내 온도를 감지하거나 시대기를 조작하는 등의 기능이 있음
    • 사용자는 이런 내부 기능에 대해 알지 못해도 에어컨을 사용하는데 문제가 없음
    • 즉, 에어컨의 내부적인 기능은 굳이 사용자에게 노출하지 않음
    • 반대로 사용자에게 필요한 기능은 사용하기 편한 형태로 제공함
    • 전원의 경우, 버튼 하나만 누르면 on/off 반복 가능, 온도 조절이나 바람 세기 조절도 버튼으로 쉽게 조작 가능
    • 이런식으로 리모컨(api/interface)를 활용하면 서비스 제공자와 요청자 간에는 미리 정의된 방식으로 통신 가능
  • Client-Server 모델 역시 이와 비슷하게 API라는 interface를 통해 데이터를 송수신함

05 REST API

• 실질적으로 API를 디자인하는 방법 알아보기!

1. RESTful API란

• 'Representational State Transfer'의 약자 → '서버에서 관리하는 데이터의 상태가 표현되는 디자인'
• API를 설계하는 스타일 가이드 중 하나, 강사님 피셜 - "가장 많이 사용되는 API 디자인 방법"
• REST API 사용 시 Client와 Server가 서로 예측 가능한 방법으로 통신 가능
  
• 특징: Resource와 Method를 통해 표현됨

1) Resource

• REST API는 URL을 통해 고유한 resource(Server에서 관리하고 있는 자원)에 대해 표현
• 예)

/api/v1/posts
/api/v1/posts/123/comments

• /api/v1/posts라는 url로 접근 시 post라는 게시물들에 대한 데이터에 접근하게 됨
• /api/v1/posts/123/comments라는 url로 접근 시 123번 게시글에 달린 댓글 데이터에 접근하게 됨

2) Method

• HTTP Method 통해 API의 동작 표현
• 예)

GET /api/v1/posts	# post 조회
POST /api/v1/posts	# post 생성
PATCH /api/v1/posts/123 # post 수정
DELETE /api/v1/posts/123 # post 삭제

• GET 메서드로 api/v1/posts에 요청/접근하면 전체 게시글 조회 가능
• POST 메서드로 api/v1/posts에 요청/접근하면 새로운 게시글 생성 가능
• PATCH 메서드로 api/v1/posts/123에 요청/접근하면 123번 게시글 수정 가능
• DELETE 메서드로 api/v1/posts/123에 요청/접근하면 123번 게시글 삭제 가능
• 위와 같이 REST API 사용 시 간결한 interface로 Client와 Server간의 통신 관리 가능

06 Status Code (상태 코드)

• 상태 코드를 통해 요청의 결과를 대략적으로 유추 가능
• 다 암기할 필요 없고 필요에 따라 검색하여 사용하기
• 자주 사용되는 상태 코드들:

큰 분류	상태 코드	설명
200번대 (요청 성공)	200 OK	요청 성공, 범용적, GET / POST / PUT / PATCH
	201 Created	요청 성공, 새로운 자원 생성, POST
	204 No Content	요청 성공, 응답할 자원 없음, DELETE
400번대 (요청 실패) (의도적으로 서버에서 발생시키는 에러)	400 Bad Request	요청 실패, 요청이 잘못된 경우 (query param, request body)
	401 Unauthorized	인증 실패
	403 Forbidden	권한 문제 또는 잘못된 method
	404 Not Found	존재하지 않은 자원 요청 또는 잘못된 endpoint 요청
500번대 (다른 에러) (예상치 못한 상황에서 발생하는 에러)	500 Internal Server Error	범용적인 서버 에러 (원인 불명확)
	502 Bad Gateway	Reverse Proxy (e.g., Nginx)에서 서버(upstream 서버)의 응답을 처리할 수 없는 경우
	503 Service Unavailable	서버가 요청을 처리할 수 없는 경우 (e.g., 서버의 일시적 부하, 서버 다운)

07 프로젝트 소개 - ToDo 서비스 (Version 1)

1. ToDo (Version 1) 서비스 만들기

1) ToDo 서비스의 기능

• 할 일을 적고 수행 여부 체크

2) ToDo API

• 생성할 API 5가지: 1) 전체 ToDo 조회, 2) 단일 ToDo 조회, 3) ToDo 생성, 4) ToDo 수정, 5) ToDo 삭제 

Method	기능	url
GET	전체 ToDo 조회	/api/v1/todos
	단일 ToDo 조회	/api/v1/todos/<id>
POST	ToDo 생성	/api/v1/todos
PATCH	ToDo 수정	/api/v1/todos/<id>
DELETE	ToDo 삭제	/api/v1/todos/<id>