• 위키백과 정의 요약

• REST 란, REpresentational State Transfer의 약자 + ful 이라는 형용사 어미(~한) + REST 기본 원칙을 성실히 지킨 서비스 디자인

• REST = Resource Oriented Architecture API 설계의 중심에 자원(Resource)이 있고 HTTP Method를 통해 자원을 처리하도록 설계하는 것

REST 6가지 원칙

• Uniform Interface
  • URI으로 지정한 리소스에 대한 조작을 통일되고, 한정적인 인터페이스로 수행하는 아키텍처 스타일
• Stateless
  • 무상태성
  • 작업을 위한 상태정보를 저장하고 관리하지 않는다. 세션 정보나 쿠키 정보를 관리하지 않음
  • Request만 Message로 처리하고, Context 정보를 신경쓰지 않아도 되서 구현이 단순
  • API 실행 중 실패 발생 시 Transaction 복구를 위해 기존의 상태를 저장할 필요가 있음
  • API 서버는 들어오는 요청만 단순 처리 한다.
• Caching
  • 캐시 가능
  • REST는 HTTP을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능 적용이 가능
• Client-Server
  • 브라우저 역할 : 요청 request → 고객은 URL 하나만 알면 서버에 있는 자료를 갖다쓸 수 있음
  • 서버 역할 : 응답 Response
• Hierarchical System
  • 계층형 시스템
  • 다층 계층으로 구성되어, 로드 밸런싱, 보안, 암호화 계층을 추가해 구조상의 유연성을 얻을 수 있음
• Code on demand
  • 서버는 고객에게 실행 가능한 코드를 전송해줄 수 있음
  • applet 이나 스크립트 전송으로 클라이언트의 기능 확장이나 커스터마이즈 가능

RESTful API 디자인의 의미

1. 리소스와 행위를 명시적이고 직관적으로 분리
   • 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 함
   • 행위는 HTTP Method로 표현하고, GET(조회), POST(생성), PUT(기존 entity 전체 수정), PATCH(기존 entity 일부 수정), DELETE(삭제)을 분명한 목적으로 사용
2. Message는 Header와 Body를 명확하게 분리해서 사용
   • Body : Entity에 대한 내용
   • Header : 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입
   • header와 body는 http headder 와 http body로 나눌 수 있고, http body에 들어가는 json 구조로 분리할 수 있음
3. API 버전을 관리
   • 환경은 항상 변하기 때문에 API의 signature가 변경될 수도 있음을 위의
   • 특정 API를 변경할 때는 반드시 하위 호환성을 보장해야 함
4. 서버와 클라이언트가 같은 방식을 사용해서 요청
   • 브라우저는 form-data 형식의 submit으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는 json으로 보내든, 둘 다 form-data 형식으로 보내든 하나로 통일
   • = URI가 플랫폼 중립적이어야 함

RESTful API의 장점

1. Open API를 제공하기 쉬움