REST?

• 역사

  • 2000년대 Roy Fielding 박사의 논문에 처음 인용됨.

  Architectural Styles and the Design of Network-based Software Architectures

  • 초간단 요약

    → 웹은 왜 이렇게 성공했고, 왜 이렇게 대규모 시스템이 성립이 된건지 소프트웨어 관점에서 분석하고 하나의 아키텍처 스타일로 정리했는데 이를 REST라 이름 지었다.

  1. 라이브러리를 개발하면서 다른 사람과 작업을 공유하고 싶음. ( 공유의 필요성 )

     • RPC 데몬을 개발. Remote Procedure Call ( 주로 유닉스 사용)
       • 보안 ,리소스 사용 취약함.

  2. 문제점 해결을 하는 동안 프로그래밍 언어, OS 에 상관 없이 해결 하도록 시도.

     • CORBA의 등장!
       • 무겁고 비쌈. ( 2000년대 1억 )
     • RMI - 자바의 RPC 데몬
       • 사내 네트워크에서는 무리 없지만, 방화벽 문제가 생긴다.
       • 기본적 방화벽은 http만 열어줌

  3. 그래서 HTTP를 쓰자!

     • 초기

       • SOAP

         • XML + HTTP 를 결한한 웹 서비스
         • Service-Oriented Architecture → 서비스지향 구조
           • 서비스를 자유자재로 정의할 수 있다 == 복잡하다.

       • ROA의 등장.

         • Resource-Oriented Architecture → 리스소 기반 구조
         • HTTP의 기본 메소드는 CURD와 매핑이 된다

          

  4. 상태값을 전달한다?

     • 결과값에 인터넷에서 발생할 수 있는 상태값을 전달한다.

       → 상태값 코드별로 대응이 가능하다.

       → 상태값 코드만 안다면 누구나 쉽게 이해할 수 있다.

     • State code 일부값

       1. 200 성공
       2. 404 Not Found
       3. 500 내부 서버 오류

     → 결과적으로 REST 구조는 HTTP 프로토콜에서 제공해주는 메커니즘을 그대로 활용한다.

• REST의 장점?

  1. 쉬운 사용
     1. 서버가 어떻게 돌아가는지 알 필요가 없고 해당 URI와 메소드 자체만 독립적으로 이해하면 됨.
  2. 클라이언트와 서버의 명확한 분리
     1. HTTP의 Stateless 한 특징
     2. 다양한 플랫폼에서 원하는 서비스를 빠르고 쉽개 배포 가능.
  3. HTTP header 와 body의 구조
     1. 헤더에 url 처리 메소드 명시
     2. body에는 필요한 데이터로 구성되어 다양한 언어를 사용할 수 있다.
  4. 웹 친화적
     • 방화벽 문제를 해결 가능
  5. 캐싱
  6. 개발자 직관적
  7. 컨텐츠 협상
     • 클라이언트가 영문 → 서버가 한글이여도 컨텐츠 협상을 통해 다르게 응답할 수 있다.

• REST의 단점

  1. 메소드의 형태가 제한적이다.
  2. 표준이 없다
     • 관리의 어려움과 공식화된 API 디자인 가이드가 없다.

구성 요소

1. Resource

   → 유일한 ID를 가지는 Resource가 서버에 존재.

   — id는 일반적으로 url을 사용한다.

   → 클라이언트 → 서버 자원의 상태를 조작하기 위해 요청을 보냄.

2. Method

   → 자원을 조작할 수 있는 것.

   • Get

     → 서버에게 Resource를 보내도록 요청.

     → 사용

     1. 자원을 읽음.

   • Post

     → 서버에 데이터를 보내기 위함.

     → 사용 :

     1. 업데이트
     2. Put과의 차이는 put은 서버 자원에 데이터를 저장 시기키 위함.
     3. Post는 데이터를 보내기 위한 용도

   • Put

     → 자원의 전체 내용을 교체할 때

     → 사용 :

     1. 모든 파라미터 (데이터의) 자원이 교체 되어야한다.

   • Delete

     → 자원을 삭제를 하도록 요청

     → 서버가 무시할 수 있다.

     → 항상 보장 되지 않음.

   • Head

     → Get과 동일하지만 서버에서 body를 주지 않음

     → 사용

     1. 자원이 존재하는지 확인
     2. 리소스 수정 되어 있는지 확인 ( context-length )

   • Connect

     → http connecct 방법.

     → http 프록시 서버에 tcp 연결을 원하는 대상으로 전달하도록 요청.

     → 사용 :

     1. 최초의 연결만 http 연결이고 이후에는 tcp 사용하여 연결함.

   • Options

     → 타겟 서버의 지원 가능한 method 확인.

   • Trace

     → 클라이언트 → Request Packet → (방화벽, Proxy Server, Gateway) → 서버

     → 이 진행 상황중 packet의 변조가 일어날 수 있다.

     → 원본 데이터와 서버 도착 데이터를 서버 응답 body를 통해 확인할 수 있다.

     → 사용

     1. 보안 취약점으로 인해 사용 중지 권장.

   • Patch

     → put과 유사하지만 부분을 바꿀 때 사용한다.

     → 사용 :

     1. 전체를 바꾸는 게 아니라 부분을 바꿀 때 사용.

3. Representation of Resource

   • 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것.

4. URI

   • Uniform Resource Identifier
   • 자원의 주소를 명시한다.

RESTFUL

REST의 제약에 따르고 있고, REST다운 것을 말한다.

필요 최소한으로 지켜야할 5가지 규칙

1. API의 ENDPOINT 가 오직 한개인가?

   • 오직 한개의 URL로 fix
   • 실제 자원에 대한 정보는 body에 전송 하도록 구현

2. 모든 방식은 POST 방식으로만 요청하는가?

   • POST , PUT, GET, DELETE 메소드를 사용해라
   • 잘한 것
     • POST /url
     • PUT /url
     • GET /url
     • DELETE /url
   • 잘못된 것
     • POST /url?cmd=insert
     • POST /url?cmd=update
     • POST /url?cmd=select
     • POST /url?cmd=delete

3. 응답에 대한 메타데이터를 BODY에 포함하는가?

   • 메타 데이터는 Header
   • Body는 오로지 리소스의 순수한데이터만!

4. URL에 동사(VERB)가 포함되어 있는가?

   • URL의 이름은 주소값 → 명사적인 특징을 가진다
   • 동사적 틍직을 가지면 혼돈이 올 수 있다.

5. URL에 RPC 호출 메서드 명령이 있는가?

   • URL에 PRC (Remote Procedure Call )사용하지 마라.