REST(Representational State Transfer)

개념

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것

• 자원 기반의 구조 설계의 중심에 자원(Resouce)이 있고 HTTP Method를 통해 자원를 처리하도록 설계된 아키텍쳐
• 웹 사이트의 이미지, 텍스트, DB 내용 들 모든 자원에 고유한 ID인 HTTP URI를 부여
• CRUD Operation
  Create(POST) : 생성
  Read(GET) : 조회
  Update(PUT) : 수정
  Delete(DELETE) : 삭제
  

구성 요소

• 자원(Resource): HTTP URI
  모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재(ID 예시 - /notice/:notice_id)
  Client는 URI를 이용해서 자원을 지정, 해당 자원의 상태(정보)에 대한 조작을 Server에 요청
• 행위(Verb): HTTP Method
  HTTP 프로토콜이 제공하는 GET, POST, PUT, DELETE(HTTP Method)사용
• 표현(Representation of Resource) : HTTP Message Pay Load
  Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)
  JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적

특징

• Client-Server 구조
  자원이 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트
  서버와 클라이언트의 역할이 구분되어 개발이 명확, 의존성 감소
• Stateless(무상태)
  HTTP 프로토콜과 마찬가지로 무상태성을 가짐
• Cacheable(캐시 처리 가능)
  웹 표준을 따라 웹의 인프라를 사용할 수 있으므로 캐싱 기능 적용 가능
• Layered System(계층화)
  클라이언트와 서버가 분리되어 중간에 프록시 서버, 로드 밸런싱, 암호화 계층 등 중간매체를 사용해 자유도를 높일 수 있음
• Uniform Interface(인터페이스 일관성)
  일관성 있는 인터페이스로 URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처
• Self-Descriptiveness(자체 표현)
  REST API 메시지만으로 그 요청이 어떤 행위인지 알 수 있음

장점

• 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용 가능

• HTTP 프로토콜 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요 X

• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능

• REST API 메시지가 의도를 명확하게 나타내므로 쉽게 파악 가능

• 서버와 클라이언트 역할을 명확하게 분리

단점

• 표준이 존재 X -> 정의 필요
• 사용 가능한 메소드가 4개 뿐이다
• 구형 브라우저가 아직 제대로 지원하지 못하는 부분 존재
  PUT, DELETE 사용 불가
• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구 됨

REST API

REST 기반으로 서비스 API를 구현한 것

규칙

• URI는 동사보다는 명사, 대문자보다는 소문자를 사용
• 마지막에 슬래시 (/)를 포함 X
• 언더바( _ ) 하이픈( - )을 사용
• 파일확장자는 URI에 포함 X
• 행위를 포함 X

RESTful

REST 원리를 따르는 시스템
REST API 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다고 할 수 있다.