최근 개발 동향

• 서버의 역할이 변화
  : 서버에서 모든 화면의 결과를 만들어내는 방식 → 서버에서 순수한 JSON 데이터만을 제공.(앱과웹에서 같은 데이터를 이용)

• 사용자 중심의 개발
  : 서버사이트가 우위였던 과거에 비해 현재는 인터페이스기능과 화면 구성에대한 사용자의 요구가 다양해지면서 백엔드/프론트엔드로 나뉨.
  : 프론트엔드는 스크립트언어에 앵글러, 뷰, 리액트, 노드등의 프레임워크가 장착되면서 사용자중심의 구현이 가능.

REST

: “Representational State Transfer” 의 약자
: 네트워크 상에서 Client와 Server사이의 통신방식중 하나.
: 자원을 이름(key)으로 구분하여 해당 자원의 정보(value)를 주고받는 모든것을 의미.
: 웹의 기존기술과 HTTP프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐

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

CRUD Operation

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

장점

• HTTP프로토콜의 인프라를 그대로 사용하므로 별도의 인프라를 구축할 필요가 없음.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능.
• Hypermedia API의 기본을 충실히 지키면서 범용성 보장.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있음.
• 서버와 클라이언트의 역할을 명확하게 분리.

단점

• 표준이 없음.
• 메소드의 형태가 제한적.
• 구형 브라우저에서 아직 지원해주지 못하는 부분이 있음. (put, delete, pushState)

필요성

• 애플리케이션 분리및 통합
• 다양한 클라이언트
  ==> 최근의 서버 프로그램은 다양한 브라우저와 모바일 환경에서도 통신을 할 수 있어야 하기 때문에 다양한 멀티플랫폼에 대한 지원이 가능한 REST방식이 적합.

구성요소

• 자원(Resource): URI
  : 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재.
  : 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI
  : Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청.

• 행위(Verb): HTTP Method
  : HTTP 프로토콜의 Method( GET, POST, PUT, DELETE)를 사용.

• 표현(Representation of Resource)
  : Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보냄.
  : REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있음.
  : JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적.

특징

• Server-Client 구조
  : 자원을 요청하는 Client와 자원을 제공하는 Server가 있음.
  : Server는 API제공 및 비즈니스 로직처리등을 맡고 Client는 context(세션, 로그인등)등을 직접 관리하고 책임짐으로써 서로간의 의존성이 줄어듦.

• Stateless (무상태)
  : Client의 context 정보를 Server에 저장하지 않음.
  : Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리.

• Cacheable(캐시처리가능)
  : 대량의 요청을 효율적으로 처리하기 위해 캐시요구.
  : 캐시 사용을 통해 응답시간이 빨라지고 성능, 자원이용률을 향상시킴.

• Layered System(계층 시스템)
  : REST Server는 다중계층으로 구성
  : API Server는 순수하게 비즈니스로직만을 수행
  : 프록시, 게이트웨이같은 네트워크 기반의 중간매체 사용가능.

• Uniform Interface (인터페이스 일관성)
  : URI로 지정한 자원에 대한 조작을 통일성있고 한정적인 인터페이스로 수행
  : 특정 언어나 기술에 종속 되지 않음.

REST API

: REST를 기반으로 서비스 API를 구현한 것.
: JSON과 같은 순수한 데이터를 제공.

설계 기본 규칙

• URI는 정보의 자원을 표현해야함.
  1) 동사보다는 명사, 대문자보다는 소문자
  2) 도큐먼트(인스턴스) 이름은 단수명사
  3) 컬렉션/스토어 이름은 복수명사

• 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE)로 표현.
  1) URI에는 메소드가 표현되면 안됨.
  2) CRUD 기능이 URI에 표현되면 안됨.
  3) 경로에서 변하는 부분은 primary key의 값으로 대체

URI 작성 규칙

• /는계층관계를 나타낼때 사용.
• URI마지막 문자는 / 를 포함하지 않음
• - 는 URI의 가독성을 높이는데 사용.
• _는 사용하지 않음.
• 대부분 소문자사용.
• 파일 확장자는 URI에 포함하지 않음.

RESTful

: REST를 REST답게 사용하기위한 방법 = REST 원리를 따르는 시스템
==> " REST API를 제공하는 웹서비스는 RESTful하다"

목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만들도록 하는 것.
• API의 이해도 및 호환성을 높이기.