API 서버와 REST

guava·2022년 1월 11일
0

파이썬/장고 웹서비스 개발 완벽 가이드 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 디자인 : 한번 읽어볼 것.

  1. 리소스를 중심으로 디자인 ex) 포스팅, 댓글, shop 등등
  2. 클라이언트에서 엑세스할 수 있는 모든 종류의 개체/서비스가 리소스에 포함
  3. 리소스마다 해당 리소스를 고유하게 식별하는 식별자 → https://my-tripscom/trips/1/
  4. 요청/응답 포맷으로 흔히 JSON을 사용
{
  "pk": 1,
  "name": "프라하 여행",
  "user_id": 100,
  "place_set": [100, 102, 200]
}
- JSON은 xml보다 기능은 적지만 용량이 작다.
- 트위터가 API 서비스 런칭 할 때, XML 및 JSON을 둘다 지원했으나, XML은 거의 사용하지 않았던 사례가 있다. JSON이 같은 용량에서 응답도 빠르고 트래픽이 적었으므로?!
  1. 균일한 (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: 지정 리소스를 제거

→멱등성: 같은 요청을 매번 해도 서버에서는 같은 결과 응답되는 성질

리소스POSTGETPUTDELETE
/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에 버전 정보를 포함시킨다.

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에 대한 이해가 필요하다. (장고가 베이스가 되어야 한다.)
  • 무작정 타이핑만 치는것이 개발이 아니다 → 탄탄한 이해와 설계 아래 탄탄한 애플리케이션이 갖춰진다.
  • 프레임워크를 쓴다는것은 그 프레임워크가 제시하는 길을 명확히 이해하고 존중하는 것에서 시작한다.

0개의 댓글