현재 Djnago Project 를 진행중인데, REST API를 적용하려 한다. 뭐든 사용하기 전에 제대로 알아보고 사용해보자

참고

해결 문제

  • REST API가 무엇인가?
  • 왜 사용 하는가?
  • 어떻게 사용하는가?

REST API란?

Representational State Transfer 의 약자로 네트워크 아키텍쳐이다. 참 언제나 이쪽 계열의 설명은 어렵다... 쉽게 말하자면 HTTP 통신을 효율적으로 사용하기 위한 네트워크 설계 구성 방법이라고 생각하면 된다

URI

먼저 REST 아키텍쳐의 기본구성인 URI 를 흔히 URL과 비교하여 알아보자

  • URL (Uniform Resource Locator) : 파일 식별자라고 불리며, 네트워크 상에서 필요한 파일이 어디 위치하는지를 나타낸다
  • URI (Uniform Resource Identifie) : 통합 식별자라고 하며, URL 처럼 파일의 위치를 나타내는 것이 아니라 원하는 자료를 식별할 수 있는 약속한 신호라고 보면 된다

ex)
http://rest.com/static/resources/image.jpg 는 static으로 지정된 폴더에 있는 resources 라는 폴더의 image.jpg 파일을 뜻하는 것이 URL 이라면,
http://rest.com/resource/image/1 은 1번 이미지 자료를 요청하는 메세지가 URI 라고 생각하면 된다

CRUD

기본적으로 HTTP 통신할 때 Method로 GET, POST 를 써왔다. 하지만 URI를 GET과 POST 만으로 통신하기엔 표현에 무리가 있다. 그래서 Method를 Create, Read, Update, Delete 의 개념으로 나누어 사용하는데, 이것을 CRUD 라고 한다

  • Create : 생성 (POST)
  • Read : 조회 (GET)
  • Update : 수정 (PUT)
  • Delete : 삭제 (DELETE)

Why use?

이전에 REST API를 왜 쓰는지 찾아봐도 HTTP를 잘 쓰기 위해서라는 글이 대부분이었다. 지금 생각해보면 참 설명하기 복잡하여 자세히 쓰기 참 애매해서 그런것 같다. (그래서 나는 전문적이기 보단 최대한 쉽게 작성하려고 한다.. 그때의 나같은 초보도 이해에 도움이 되도록~)

1. 서버(백엔드)와 클라이언트(프론트엔드)를 분리하기 좋다

이전엔

웹의 문제는 이전에 사용하던 웹 방식이 프론트와 백엔드가 너무 서로 연관되어 있다는 것이였다. 아무래도 페이지별로 정적인 HTML 파일로 나누어져 있고 서버에서 랜더링을 하다보니, 서버에서는 프론트엔드 부분을 건드릴 수 밖에 없고 분리란 힘든 상황이었다

요즘은

HTML5가 나오면서 프론트엔드가 크게 변화했다. 백엔드와 분리되어 웹 퍼블리셔가 아닌 프론트엔드 개발자로 자리를 잡았다. 프론트가 이렇게 떠오르게 된 가장 큰 이유는 새로고침해야 서버에서 데이터를 불러오는 정적인 웹페이지가 아니라, 데이터를 받아 새로고침없이 랜더링하는 동적인 웹페이지가 가능해진 것이다

결국 동적인 웹이 가능해지면서 프론트에서 변화한 데이터를 HTTP로 요청하면 서버는 랜더링이 필요없이 필요한 데이터만 프론트로 보내주면 된다. 이 때 필요한 것이 REST API이다. URL(파일 식별자)로 파일위치를 보내주는 것이 아니라, URI(통합 식별자)로 서로 어떤 데이터를 주고 어떤 데이터를 받는지 표현하게 되었다

2. 다양한 클라이언트

이제 서버와 클라이언트가 분리 되었는데다가 모바일, 태블릿 등 다양한 클라이언트 플랫폼이 생겨났다. 근데 만약 이전처럼 서버가 클라이언트랑 연관되어 있다면 각 플랫폼마다 API를 따로 만들어야 할 것이다

하지만 분리가 되었으니 여러 플랫폼의 클라이언트에서 같은 URI로 요청을 하면 같은 데이터를 반환해주면 된다

REST API 설계 규칙

  • 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
    Ex) http://restapi.example.com/houses/apartments

  • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.

  • REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
    Ex) http://restapi.example.com/houses/apartments/ (X)

  • 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.( 언더바( _ )은 URI에 사용하지 않는다)

  • URI 경로에 대문자 사용은 피하도록 한다.

  • 파일확장자는 URI에 포함하지 않는다.
    Accept header를 사용한다.
    Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
    Ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)

  • 리소스 간에는 연관 관계가 있는 경우
    /리소스명/리소스 ID/관계가 있는 다른 리소스명
    Ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)

이렇게 REST 규칙을 따른 웹을 RESTful 하다고 표현한다