💻 Today I Learned

그동안 REST API를 설계하면서 자원(Resource)에 대한 행위는 HTTP Method(POST, GET, PUT, DELETE)를 통해 CRUD 기능을 구현했다.

하지만 Restful 하다는 의미와, REST API를 옳게 설계를 하고 있는 것인지 스스로에 대한 의심이 생겨 REST API에 대한 개념과 설계 방법에 대해 찾아보았다.

URL과 URI

먼저 REST API를 알아보기 전에 URI에 대한 개념 정리가 필요한 것 같다.

URI(Uniform Resource Identifier)는 통합 자원 식별자이며 인터넷에 있는 자원을 어디에 있는지 자원 자체를 식별하는 방법이다.

URL(Uniform Resource Locator)은 네트워크 상에서 자원이 어디 있는지 위치를 알려주기 위한 규약이다.

URL과 URI의 차이는 자원의 위치는 동일하지만, 자원의 식별자를 포함하는 것이 URI다.

만약 http://www.naver.com/index.html?page=1232950&id=776 라는 웹페이지의 주소가 있을 때,
index.html이라는 자원에서 내가 원하는 정보에 도달하기 위해서는 ?page=1232950&id=776라는 식별자(Identifier)가 필요하다.

따라서 식별자가 빠진 index.html 까지가 URL이자 URI이며 자원의 식별자가 포함된 것이 URI다.

• 참고한 블로그

REST 란?

REST는 HTTP라는 프로토콜을 이용해서 Web에서 제공하는 모든 자원들을 하나하나 가리킬 수 있는 고유한 주소(URI)를 이용하여 HTTP Method를 통해 작업(CRUD)를 처리하는 방식이다

Representational -> 표현, 묘사
State -> 상태
Transfer -> 전송

REST의 구성 요소로는 자원(Resource), 행위(Verb), 표현(Representation)이 있다.

• 자원(Resource) :자원은 서버에 존재하는 데이터의 총칭으로 모든 자원은 고유의 URI(URL)을 가지며 클라이언트는 이 URI를 지정하여 해당 자원을 식별할 수 있다.

• 행위(Verb) : HTTP 프로토콜에 있는 Method를 통해 CRUD를 처리
  👉 Method : POST, GET, PUT ,DELETE

• 표현(Representation) : 클라이언트에서 자원의 상태(정보)를 HTTP Method로 조작하는 요청을 하고 서버에서 요청을 처리 후 응답을 보낸다.
  👉 자원은 보통 TEXT, JSON, XML, HTTP 헤더에 지정된 MIME타입(Content-Type)중 하나를 표현

REST API란?

REST는 Representational State Transfer의 약어로서 웹의 장점과 HTTP의 우수성을 제대로 활용할 수 있는 아키텍처이다. HTTP URI를 통해서 자원을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해서 명시된 자원의 CURD 연산을 적용하는 것을 의미한다.

따라서 REST는 자원(Resource), 행위(Verb), 표현(Representations)으로 구성된 아키텍처라 볼 수 있으며 코드의 재사용성을 높일 수 있으며 프론트엔드와 백엔드의 완전한 분업이 가능하다.

REST API를 사용하는 이유?

REST API를 사용하는 이유는 코드의 재활용성을 높이고, 백엔드와 프론트의 분리를 위함이다.

기존의 방식은 한 페이지당 하나의 클래스 혹은 함수의 views.py 코드가 필요했지만, REST API를 사용함으로써 HTML&JS 페이지가 여러 API에서 정보를 받을 수 있다.

즉, 1개의 API가 100개, 1000개, 10만 개의 페이지에서 활용될 수 있다는 것이다.

그리고, Django Template으로 백엔드에서 보낸 정보를 프론트에서 받는다면 프론트를 담당하는 개발자가 Django Template filter로 정보를 받아야 하는데, 이렇게 된다면 프론트와 백엔드는 서로 끊임없이 연락하고 함께 코드를 합치고 고치는 일이 잦아질 것이며 개발 속도는 느려질 수밖에 없다.

작업의 효율성을 높이기 위해서는 백엔드와 프론트는 완전히 구별되는 것이 이상적이며 그러기 위해서는 REST API 필요하다.

REST API의 특징

• Uniform Interface
  URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다. HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능하다

• Stateless
  작업을 위한 상태 정보(쿠키, 세션)를 보관하거나 관리하지 않고 요청만 처리하면 되므로 구현이 단순해진다.

• Cacheable
  웹 표준 프로토콜을 그대로 사용하므로 기존의 인프라를 활용할 수 있으므로 캐싱 기능을 사용할 수 있다.

• Self-descriptiveness
  REST API 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다.

• Client-Server
  자원을 가진 쪽이 Server, 자원을 요청하는 쪽이 Client 각각의 역할이 확실히 구분되기 때문에 서로간 의존성이 줄어들게 됨

  Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임
  Client : 사용자 인증이나 상태정보를 직접 관리하고 책임

• Layered System
  REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

REST API의 디자인 가이드

핵심은 URI는 자원(Resource)을 표현하는데 집중하고, 자원에 대한 행위(Verb)는 HTTP Method로 처리하는 것이다.

• 슬래시는 계층 관계를 나타낼 때 사용
• 마지막 문자로 슬래시를 포함하지 않음
• 하이픈은 가독성 높이는데 사용
• 언더바는 사용하지 않음
• 소문자가 적합함
• 파일 확장자는 포함하지 않음

members라는 자원(Resource)가 있을 때 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

GET    /members (회원 정보 가져옴)
POST   /members (회원 정보 추가함)
PUT    /members (회원 정보 수정함)
DELETE /members (회원 정보 삭제함)