[Theory] Restful API란

Restful API란 무엇인가?

Rest란 Representational State Transfer의 약자로서 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. Rest는 네트워크 아키텍쳐의 모음으로서 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. Rest 아키텍처에 적용되는 6가지 제한 조건이라고 하여 아래와 같은 조건이 있다.

Rest 아키텍처에 적용되는 6가지 제한 조건

  1. 클라이언트/서버 구조: 일관적인 인터페이스로 분리되어야 한다.
  2. Stateless: 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안된다.
  3. 캐시 처리 가능: WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
  4. 계층화: 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상시키는 데 유용하다.
  5. Code on demand: 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
  6. 인터페이스 일관성: 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.

클라이언트와 서버의 구조에 대해서 얘기를 해보면 결국 클라이언트와 API 서버가 분리가 되어 API 서버의 결국 클라이언트에서 요청만을 처리해주면 된다. 종종 프로젝트의 소스를 보면 View에서도 비지니스 로직을 처리하는 소스가 있는 경우가 있는데 이러한 경우 대부분 기술 부채에 대한 부담을 가질 수 밖에 없는 것 같다.

Rest 설계 원칙

Restful API를 설계하는 데에는 몇 가지 원칙이 있다. 사실 Front-end로서 일하는 나로서는 실제 Restful API 설계를 직접할 일이 그렇게 많지도 않을 뿐만 아니라 실제 비니지스를 운영해본적도 없었다. 그래서 그냥 서버에서 제공해주는 데로만 사용하다 마침 회사에서 새롭게 들어가는 프로젝트에서 우연히 API 통신에 대한 규약을 서버와 맞춰볼 일이 생겨 이 참에 살펴보게 되었다. 그 중 나와 제일 연관이 있는 원칙 두가지를 꼽아본다면 자원의 식별메시지를 통한 리소스의 조작 원칙이 아닐까 싶다.

클라리언트에서는 API의 URI만 보고도 그에 대한 자원을 식별할 수 있어야 한다.

[Get] /api/students 
[Put] /api/notice/:id

예를 들어 위의 URI를 살펴보면 어느 정도 요청 혹은 요청에 따른 response를 유추할 수 있다. 물론 이와 같이 식별이 된다는 것은 해당하는 URI에 대한 Method 역시 확장성이 있게 사용할 수 있다.

[Get] /api_v1/students
[Post] /api_v1/students
[Update] /api_v1/students
[Put] /api_v1/students

위의 URI만 봐도 기본적인 CRUD에 해당하는 Method 들을 확장성 있게 사용할 수 있음을 알 수 있다. 또한 api의 버전이 갱신에 대한 확장성 역시 명확해질 수 있다. 또한 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 그 자료를 HTML, XML, JSON, Text와 같은 형식으로 전달할 수 있다. URI 요청에 대한 Method는 Deployd 자료에서 대략적으로 정리하였으니, 자료가 궁금하면 여기 에서 확인하면 된다.

물론 위와 같이 명확하게 설계가 되려면 클라이언트와 서버쪽에도 충분한 커뮤니케이션과 또한 그에 해당하는 문서가 필요하겠지만, 위와 같이 하나의 서로 간의 규칙을 맞춰놓는다면 클라이언트에서 어느 정도 유추를 할 수 있을 것이다.


출처

Comments