01. REST의 개념

• 2000년 로이 필딩(Roy Fielding)이 박사학위 청구 논문에서 REST(Representational State Transfer)를 소프트웨어 아키텍처 스타일로 제안

• REST : Representational State Transfer
  • 자원(resource)의 표현(representation) 에 의한 상태(State) 전달
    • 자원: 문서, 그림, 데이터, 소프트웨어 자체 등
    • 표현: 그자원을 표한하기 위한 이름 예) 영화=movies
    • 상태: 자원의 상태를 전달
      • PUT: 자원이 업데이트된 상태
      • POST: 자원이 새로 추가된 상태
      • GET: 자원을 읽은 상태
      • DELETE: 자원이 삭제된 상태

Image Added

02. REST이전

Image Added

• 단점
  • 개발자마다 API설계가 다르다.
  • CRUD를 만들기 위해 API를 여러개 만들어야 한다.

03. HTTP의 역사

• HTTP/0.9

  • 1991년 월드와이드 웹 공식출발과 함께 시작

  • method : GET

  • Header가 없음

  • GET /mypage.html

• HTTP/1.0

  • 1996년 11월  RFC 1945에 공개

  • HTTP Header및 Content-Type추가로 HTML이외의 문서도 전송가능

  • method: GET, POST
  • GET /mypage.html HTTP/1.0
• HTTP/1.1
  • 1997년 1월 RFC 2068에서 처음 공개
  • HTTP의 첮번째 표준
  • method: GET, POST, OPTIONS, PUT, DELETE, TRACE
• HTTP/2
  • 2015년 5월 공식 표준화

04. REST API

• REST기반으로 서비스 API를 구현한것
• REST API의 특징
  1. Server-Client구조
  2. Stateless(무상태)
     
     • 세션이나 쿠키등을 별도로 관리하지 않습니다.
     • 클라이언트의 컨텍스트를 서버쪽에 유지하지 않습니다.
  3. Cacheable(캐시 처리 가능)
     • HTTP가 가진 캐싱 기능이 적용 됩니다.
     • HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
  4. Self-descriptiveness (자체 표현 구조)
     • REST 구조만 보아도 쉽게이해할 수 있는 자체 표현 구조를 가지고 있습니다.
  5. Layered System(계층화)
     • 클라이언트 입장에서는 REST Api서버만 호출한다. 
     • Rest server를 다중 계층으로 구성
       • 보안, LB, 암호화, 인증등의 계층을 추가.
  6. Uniform Interface(인터페이스 일관성)
     • URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.

• Info
  1~5특징은 이미 HTTP프로토콜에 포함된 개념 입니다.

• 장점
  • API디자인에서 발생할 수 있는 문제를 최소화 한다.
  • 서버와 클라이언트 역할을 명확하게 분리한다.
  • API가 의도하는 바를 쉽게 파악할 수 있다.
  • HTTP표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.
• 단점
  • 표준이 존재하지 않는다.
  • 사용할 수 있는 메소드가 4가지 밖에 없다.

Image Added

• 버전관리
  • http://domain.com/api/v1.0/users

05. RESTful

• RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
  • ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
• RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
  • 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
• RESTFUL의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이다.

06. REST Api 설계하기

• 디자인 가이드
  • 첫째: URI는 정보의 자원을 표현해야 한다.
  • 둘째: 자원에 대한 행위는 HTTP Method로 표현한다.
  • 셋째: 응답 코드는 HTTP Status Code로 응답한다.
• API 설계
  • 01. URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)
    • GET /members/:id
    • DELETE /members/:id
  • 02. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다. (마지막 문자로 슬래시를 포함하지 않는다.)
    • GET /houses/apartments
    • GET /animals/dogs
  • 03. 하이픈 (-)은 URI 가독성을 높이는데 사용한다.
    • GET /toomushlongstring-home/:id
  • 04. 밑줄(_)은 URI에 사용하지 않는다.
  • 05. URI 경로에는 소문자가 적합하다. (RFC 3986 is the URI Syntax document)
  • 06. 파일 확장자는 URI에 포함시키지 않는다. (Header의 Application-type)
  • 07. 리소스 간의 관계를 표현하는 방법
    • GET /리소스명/리소스ID/관계가 있는 다른 리소스명
    • GET /users/:id/devices
  • 08. 자원을 표현하는 Collection과 Document (sports와 players는 컬렉션 soccer는 도큐먼트)
    • GET /sports/soccer/players/:id
  • 09. HTTP 응답 상태 코드
    • GET /members/:id → Http Status code: 404

07. REST API 설계해 보기

• Info
  SNS서비스를 제공하는 회사가 있습니다. 특정회원의 친구 목록을 조회 하려고 합니다. REST API를 설계 하세요. GET /restapi/v1.0/:id/friends GET /users/v1.1/:id/friends GET /restapi/v1.2/users?type=friends GET /restapi/v1.3/users/:id?type=friends GET /restapi/v1.4/users/:id/friends