파이썬/장고 웹서비스 개발 완벽 가이드 with 리액트 강의를 듣고 정리한 글입니다.
API 서버란?
앱 / 웹 서비스를 만드는 개발자들이 이용하는 데이터 위주의 응답을 하는 서비스. 시간이 지나도 호환성을 유지해야 한다.
- 앱 등의 유저가 사용하는 UI는 유저가 원할 때 업데이트 된다.
- 유저층이 사용하는 앱의 버전이 다양하기에, API에도 버전 개념을 둔다. ex)
/api/v1/posts,/api/v2/posts - App에 반해 , 웹 서비스를 이용하는 유저는 항상 최신 버전을 사용한다.
Client to Server 통신
→ 클라이언트 요청 시 서버로부터 html, 엑셀, xml응답 등이 있다. 주로 html 응답이다.
REST (Representational State Transfer)
아키텍처 스타일. 프로토콜에 독립적 → 일반적인 REST 구현에서 HTTP를 사용
RESTful API의 몇 가지 디자인 원칙
[Azure 아키텍처] Web API 디자인 : 한번 읽어볼 것.
- 리소스를 중심으로 디자인 ex) 포스팅, 댓글, shop 등등
- 클라이언트에서 엑세스할 수 있는 모든 종류의 개체/서비스가 리소스에 포함
- 리소스마다 해당 리소스를 고유하게 식별하는 식별자 →
https://my-tripscom/trips/1/ - 요청/응답 포맷으로 흔히 JSON을 사용
{
"pk": 1,
"name": "프라하 여행",
"user_id": 100,
"place_set": [100, 102, 200]
}- JSON은 xml보다 기능은 적지만 용량이 작다.
- 트위터가 API 서비스 런칭 할 때, XML 및 JSON을 둘다 지원했으나, XML은 거의 사용하지 않았던 사례가 있다. JSON이 같은 용량에서 응답도 빠르고 트래픽이 적었으므로?!-
균일한 (uniform)인터페이스를 적용
리소스에 표준 HTTP동사 (GET, POST, PUT, PATCH, DELETE)를 적용
리소스를 중심으로 API를 구성
리소스 중심일 때와 아닐 때
/order/로의 POST 요청/create-order/로의 POST 요청
→ 동사를 URL로 명시하기보다, 리소스를 명시하고 HTTP 동사로서 역할을 구별한다.
리소스 중심의 설계
/customer/→ 고객 컬렌션/customer/5/→ pk가 5인 고객 → 직관적인 웹 API/customer/5/orders/→ 고객 5에 대한 모든 주문/order/99/customer/→ 주문 99의 고객
심플하게 URI를 구성하기
요구사항: 1번 고객의 주문들 중 99번 주문에 대한 제품들
/customer/1/orders/99/products/→ 유연성이 떨어짐 (API, 스키마 등 비지니스 요구사항이 바뀌었을 때 좋지 않다.)
유사한 작업을 하지만 다음과 같이 나누어서 작업하여 URI를 심플하게 구성한다.
/customers/1/orders/를 통해 고객 1의 모든 주문을 찾은 후에/order/99/products/로 변경해서 동일하게 처리
/providers/masters/
/providers/managers/HTTP 메서드를 기준으로 기본 작업 정의
GET: 리소스의 표현. 응답 본문에 리소스의 세부 정보POST: 새 리소스 생성 요청. 응답 본문에 새 리소스의 세부 정보를 제공 → 멱등성(idempotent) 미보장PUT: 기존 리소스를 대체. 요청 본문에 갱신할 리소스 정보를 제공 → 반드시 멱등성이 보장되어야 함PATCH: 기존 리소스를 부분 대체. 요청 본문에 갱신할 리소스 정보를 제공. → 멱등성 미보장.DELETE: 지정 리소스를 제거
→멱등성: 같은 요청을 매번 해도 서버에서는 같은 결과 응답되는 성질
| 리소스 | POST | GET | PUT | DELETE |
|---|---|---|---|---|
| /posts/ | 새 포스팅 만들기 | 모든 포스팅 목록 | 포스팅 대량 업데이트 | 모든 포스팅 삭제 |
| /posts/1 | 오류 | 포스팅 1에 대한 내용 | 포스팅 1의 정보 갱신 | 포스팅 1 삭제 |
| /posts/1/comments/ | 포스팅 1의 새 댓글 만들기 | 포스팅 1에 대한 모든 댓글 목록 | 포스팅 1의 댓글 대량 업데이트 | 포스팅 1의 모든 댓글 삭제 |
요청 / 응답 형식 지정
Content-Type 헤더
application/json,application/vnd.ms-excel,image/json,application/pdf등이 있다.- 요청 시에 처리를 원하는 형식으로 지정하면 서버에서는 이 형식으로 응답해준다.
- 서버에서 해당 형식을 지원하지 않으면 HTTP 상태 코드 415 (지원하지 않는 미디어 유형)반환
HTTP METHOD별 다양한 상태 코드
GET: 일반적으로 200(OK) 응답, 리소스를 못 찾을 경우 404(Not Found)응답POST- 201 (Created) 응답. 새 리소스의 URI는 응답의 Location 헤더에 담는다.
- 새 리소스를 만들지 않은 경우, (ex. 업데이트를 구현 하였을 경우)
- 200 응답 하고 응답 본문에 포함하거나
- 반환할 결과가 없으면 204(내용없음)를 반환할 수도 있다.
- 잘못된 데이터로 요청하면 400(잘못된 요청) 응답하고 응답 본문에 오류 정보 또는 자세한 정보를 제공하는 URI 링크를 포함한다.
PUT: 기본 리소스를 업데이트 할 경우 200(OK) 또는 204(내용 없음)반환. 상황에 따라 업데이트 할 수 없는 경우 409(충돌)반환.DELETE: 성공하면 응답 본문에 추가 정보가 포함되지 않았음의 의미로 204 응답. 리소스가 없는 경우 404 응답.- 비동기 작업
- 작업 완료에 시간이 오래 걸릴 경우, 다른 Task Queue를 통해 비동기 처리를 할 수 있다. (Celery) 이 때 요청은 수락되었지만 아직 완료되지 않았음을 나타내는 202(수락됨)을 응답.
- 클라이언트가 이 작업을 Polling을 통해 모니터링 할 수 있도록, 비동기 요청의 상태를 반환하는 URI를 Location헤더로 반환. (Poling : 주기적으로 어떠한 대상을 검사함)
HTTP API? RESTFUL API
- 단순히 HTTP프로토콜을 통한 API는 HTTP API라고 불러야 적절하다. 혹은 Web API.
- 대부분의 REST API라는 API들은 REST 아키텍처를 지키지 않은 경우가 많음.
- REST API는 REST 아키텍처를 준수하여야 함.
→ Web API ≥ HTTP API > REST API
Django Rest Framework
- 장고의 패러다임 하에 빠르고 관리하기 쉬운 API를 만들 수 있다.
- DRF는 아래 REST API 컨셉을 쉽게 만들 수 있도록 도와준다.
- 아래가 REST API의 전부는 아니다. (다만 DRF는 아래의 철학을 어느정도 기본적으로 지원한다.)
- URI는
http://{serviceRoot}/{collection}/{id}형식이어야 한다. - GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 한다.
- API 비저닝은 Mafor.minor로 하고, URI에 버전 정보를 포함시킨다.
- URI는
Django Rest Framework의 주요 기능들
- Serializer/ModelSerializer를 통한 데이터 유효성 검증 및 데이터 직렬화 → 장고 Form/ModelForm의 기능과 유사
- 각종 Parser를 통한 일관된 데이터 처리
- APIView/Generic/ViewSet/ModelViewSets를 통한 요청 처리
- 각종 Renderer를 통한 다양한 응답 포맷 지원 (excel, yaml, pdf 등)
- 인증(Authentication)/권한(Permission)체계 - 써드파티를 통해 JWT(Json Web Token) 지원 (DRF 기본 인증 라이브러리는 기한제한이 없는 Token인증만 지원함)
- Throttling (최대 호출 횟수 제한) free유저는 100회의 호출 지원, premium은 10000회를 지원하는 등의 서비스가 가능.
CRUD
모든 데이터는 기본적으로 추가/조회/수정/삭제액션으로 관리될 수 있다.
- -C : Create (생성) : 새 레코드 생성
- -R : Read, Retrieve (조회) : 레코드 목록 조회, 특정 레코드 조회
- -U : Update (수정) : 특정 레코드 수정
- -D : Delete (삭제) : 특정 레코드 삭제
주의) CRUD는 리소스에 대한 대표적인 동작일 뿐, API의 전부는 아님
- 데이터 관리는 CRUD가 대표적인 동작이다.
DRF는 리소스(모델)만 정의되면 CRUD를 만들 수 있는 기틀이 잘 되어 있음 + 추가적인 동작 또한 잘 구현할 수 있도록 기반이 잘 되어 있다.
프레임워크를 쓴다는 것은 ...
- DRF에 대해 보다 심도있는 이해를 하기 위해서는 장고의 Model/Form에 대한 이해가 필요하다. (장고가 베이스가 되어야 한다.)
- 무작정 타이핑만 치는것이 개발이 아니다 → 탄탄한 이해와 설계 아래 탄탄한 애플리케이션이 갖춰진다.
- 프레임워크를 쓴다는것은 그 프레임워크가 제시하는 길을 명확히 이해하고 존중하는 것에서 시작한다.
