천소희

기록하는 개발자

업데이트:

카테고리:

/

태그: , ,

REST(Representational State Transfer)란?

자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미
자원의 표현에 의한 상태 전달

  1. 자원의 표현
    • 자원: 해당 소프트웨어가 관리하는 모든 것
    • ex) 문서, 그림, 데이터, 소프트웨어 자체)
    • 자원의 표현: 그 자원을 표현하기 위한 이름
    • ex) DB의 학생 정보가 자원이면 ‘students’를 자원의 표현이라 한다.
  2. 상태 전달
    • 데이터가 요청되는 시점에서 자원의 상태를 전달
    • JSON 혹은 XML를 통해 데이터를 주고 받는다.

REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문의 웹의 장점을 활용할 수 있는 아키텍쳐 스타일이다.

HTTP URL을 통해 자원을 명시하고 HTTP Method를 통해 해당 자원에 대한 CURD를 적용한다.

  • POST: 생성
  • GET: 조회
  • PUT: 수정
  • DELETE: 삭제
  • HEAD: header 정보 조회

장점

  • HTTP 프로토콜을 사용하므로 REST API를 위한 인프라를 구축할 필요가 없다.
  • HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능하다.
  • REST API 메세지가 의도하는 바를 명확하게 나타나므로 의도하는 바를 쉽게 파악할 수 있다.
  • 서버와 클라이언트의 역할을 명확하게 분리한다.

단점

  • 표준이 존재하지 않는다.
  • 사용할 수 있는 메서드가 4가지밖에 없어 제한적이다.
  • 구형 브라우저가 제대로 지원하지 않는 메서드(PUT, DELETE, pushState)가 있다.

왜 필요한가?

  • 애플리케이션의 분리 및 통합
  • 다양한 클라이언트의 등장
  • 최근의 서브는 다양한 브라우저와 안드로이드, 아이폰과 같은 모바일 디바이스에서도 통신이 되야한다.

특징

  1. Server-Client
    • REST Server(자원 저장): API를 제공하고 비즈니스 로직 및 저장을 책임
    • Client(자원 요청): 사용자 인증이나 세션, 로그인 정보 등을 직접 관리하고 책임진다.
    • 서로 간의 의존성이 줄어든다.
  2. Stateless(무상태)
    • HTTP 프로토콜은 Stateless 프로토콜이므로 REST 역시 Stateless을 갖는다.
    • Client의 세션, 로그인 정보는 Server에 저장하지 않는다.
    • Server는 쿠키와 세션같은 정보를 신경쓰지 않아도 되니 구현이 단순해진다. - Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리한다.
    • 각 API 서버는 Client 요청만 단순하게 처리한다.
    • 이전 요청이 다음 요청의 처리에 연관이 있어서는 안된다.
    • 하지만 이전 요청이 DB를 수정하여 변경이 생기는 경우에 한에 허용한다.
    • Server 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아진다.
  3. Cachealbe(캐시 처리 가능)
    • HTTP가 가진 캐싱 기능을 사용할 수 있다.
    • 대량의 요청을 효율적으로 처리하기 위해서 캐시가 요구된다.
    • 캐시 사용으로 응답 시간이 빨라지고 트랜젝션이 발생하지 않기 때문에 전체 응답시간, 성능, 서버 자원 이용률을 향상시킬 수 있다.

    캐시(cache)
    자주 사용하는 데이터가 값을 미리 복사해 놓는 임시장소로 저장공간이 작고 비싼 대신 빠른 성능 제공한다.

    이런 경우 cache 사용을 고려하면 좋다.

    • 접근 시간에 비해 데이터에 접근하는 시간이 오래 걸리는 경우
    • 반복적으로 동일한 결과를 돌려주는 경우(이미지, 썸네일…)

    cache는 반복적으로 데이터를 불러오는 경우에, Memory에 데이터를 저장하였다가 불러다 쓰는 것을 의미한다.
    DBMS의 부하를 줄이고, 성능을 높이기 위해 캐시를 사용한다.
    단, 저장공간이 작기 때문에 전략에 따라서 저장 데이터를 변경해야된다.

  4. Layered System(계층화)
    • Client는 REST API Server만 호출한다.
    • REST API Server는 다중 계층으로 구성 될 수 있다.
    • API Server는 순수 비지니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증을 추가하여 구조상의 유연성을 줄 수 있다.
    • 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다. - PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
  5. Code-On-Demand(optional)
    • Server로 부터 스크립트를 받아서 Client에서 실행한다.
    • 반드시 충족할 필요할 필요는 없다.
  6. Uniform interface(인터페이스 일관성)
    • URL로 지정한 Resource에 대한 조작을 통일하고 한정적인 인터페이스로 수행한다.
    • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.

RESTful API

  • REST를 기반으로 서비스 API를 구현한 것
  • 최근 Open API, 마이크로 서비스 등을 제공하는 업체는 대부분 RESTful API를 제공한다.

특징

  • 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
  • HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
  • REST API를 제작하면 델파이 클라이언트 뿐만 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.

설계 기본 규칙

  • 도큐먼트: 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
  • 컬랙션: 서버에서 관리하는 디렉터리라는 리소스
  • 스토어: 클라이언트에서 관리하는 리소스 저장소
  1. URI는 정보의 자원을 표현해야된다. a. 동사보다는 명사, 대문자보다는 소문자를 사용 b. 도큐먼트의 이름은 단수명사 c. 컬렉션과 스토어의 이름은 복수명사
    • ex) GET /Member/1 -> GET /members/1
  2. 자원에 대한 행위는 HTTP Method로 표현한다. a. URI에 Method가 들어가면 안된다. b. URI에 행위에 대한 동사 표현이 들어가면 안된다.
    • ex) GET /members/insert/2 -> POST /members/2 c. 경로 부분 중 변하는 부분은 유일한 값을 대체
  3. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.
  4. URI의 마지막 문자로 슬래시를 포함하지 않는다.
  5. 하이픈(-)은 URI의 가독성을 높이는데 이용한다.
  6. 밑줄(_)은 URI에 사용하지 않는다.
  7. URI 경로에는 소문자가 적합하다.
  8. 파일확장자는 포함하지 않는다.
  9. 리소스 간에 연관 관계가 있을 때는 /리소스명/리소스ID/관계가 있는 다른 리소스명으로 작성한다.

참고