파이썬/장고 웹서비스 개발 완벽 가이드 with 리액트 강의를 듣고 정리한 글입니다.
앱 / 웹 서비스를 만드는 개발자들이 이용하는 데이터 위주의 응답을 하는 서비스. 시간이 지나도 호환성을 유지해야 한다.
/api/v1/posts
, /api/v2/posts
Client to Server 통신
→ 클라이언트 요청 시 서버로부터 html, 엑셀, xml응답 등이 있다. 주로 html 응답이다.
아키텍처 스타일. 프로토콜에 독립적 → 일반적인 REST 구현에서 HTTP를 사용
RESTful API의 몇 가지 디자인 원칙
https://my-tripscom/trips/1/
{
"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)를 적용
/order/
로의 POST 요청/create-order/
로의 POST 요청→ 동사를 URL로 명시하기보다, 리소스를 명시하고 HTTP 동사로서 역할을 구별한다.
/customer/
→ 고객 컬렌션/customer/5/
→ pk가 5인 고객 → 직관적인 웹 API/customer/5/orders/
→ 고객 5에 대한 모든 주문/order/99/customer/
→ 주문 99의 고객요구사항: 1번 고객의 주문들 중 99번 주문에 대한 제품들
/customer/1/orders/99/products/
→ 유연성이 떨어짐 (API, 스키마 등 비지니스 요구사항이 바뀌었을 때 좋지 않다.)유사한 작업을 하지만 다음과 같이 나누어서 작업하여 URI를 심플하게 구성한다.
/customers/1/orders/
를 통해 고객 1의 모든 주문을 찾은 후에/order/99/products/
로 변경해서 동일하게 처리/providers/masters/
/providers/managers/
GET
: 리소스의 표현. 응답 본문에 리소스의 세부 정보POST
: 새 리소스 생성 요청. 응답 본문에 새 리소스의 세부 정보를 제공 → 멱등성(idempotent) 미보장PUT
: 기존 리소스를 대체. 요청 본문에 갱신할 리소스 정보를 제공 → 반드시 멱등성이 보장되어야 함PATCH
: 기존 리소스를 부분 대체. 요청 본문에 갱신할 리소스 정보를 제공. → 멱등성 미보장.DELETE
: 지정 리소스를 제거→멱등성: 같은 요청을 매번 해도 서버에서는 같은 결과 응답되는 성질
리소스 | POST | GET | PUT | DELETE |
---|---|---|---|---|
/posts/ | 새 포스팅 만들기 | 모든 포스팅 목록 | 포스팅 대량 업데이트 | 모든 포스팅 삭제 |
/posts/1 | 오류 | 포스팅 1에 대한 내용 | 포스팅 1의 정보 갱신 | 포스팅 1 삭제 |
/posts/1/comments/ | 포스팅 1의 새 댓글 만들기 | 포스팅 1에 대한 모든 댓글 목록 | 포스팅 1의 댓글 대량 업데이트 | 포스팅 1의 모든 댓글 삭제 |
application/json
, application/vnd.ms-excel
, image/json
, application/pdf
등이 있다.GET
: 일반적으로 200(OK) 응답, 리소스를 못 찾을 경우 404(Not Found)응답POST
PUT
: 기본 리소스를 업데이트 할 경우 200(OK) 또는 204(내용 없음)반환. 상황에 따라 업데이트 할 수 없는 경우 409(충돌)반환.DELETE
: 성공하면 응답 본문에 추가 정보가 포함되지 않았음의 의미로 204 응답. 리소스가 없는 경우 404 응답.→ Web API ≥ HTTP API > REST API
http://{serviceRoot}/{collection}/{id}
형식이어야 한다.모든 데이터는 기본적으로 추가/조회/수정/삭제
액션으로 관리될 수 있다.
주의) CRUD는 리소스에 대한 대표적인 동작일 뿐, API의 전부는 아님
DRF는 리소스(모델)만 정의되면 CRUD를 만들 수 있는 기틀이 잘 되어 있음 + 추가적인 동작 또한 잘 구현할 수 있도록 기반이 잘 되어 있다.