Wonryang Heo

Wonryang Heo

I want to be a goood developer

RESTful

Date:     Updated:

Categories:

Tags: , ,

** DVIEW 2017 영상을 참고하였습니다. **

❓ REST가 나온 계기

  • 어떻게 인터넷에서 정보를 공유할 것인가?(1991년)

    • 정보를 하이퍼텍스트로 연결하자!
      • 표현 형식 : HTML
      • 식별자 : URI
      • 전송방법 : HTTP

  • HTTP 1.0 출범 시기에 Roy T. Fielding의 고민

    • 어떻게 하면 Web을 망가뜨리지 않고 HTTP를 진보시킬까?
      • HTTP Object Model
      • 4년후에 이것은 REST로 발전하게 됨.(1998)

❓ 그래서 REST API는?

  • REST 아키텍쳐 스타일을 따르는 API

    • 그럼 REST는?
      • 분산 하이퍼미디어시스템을 위한 아키텍처 스타일
      • 아키텍처 스타일이란 제약조건의 집합

  • REST를 구성하는 스타일

    • client - server
    • stateless
    • cache
    • uniform interface
    • layered system
    • code on demand(optional)
      • 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다(예시 : JS)

  • uniform interface

    • identification of resource -리소스가 uri로 식별되면 된다.
    • manipulation of resources through representations
      • repersentation 전송을 통해 resource를 조작한다.
      • 만들거나 업데이트하거나 삭제하거나 할 때 message에 표현을 담아야 한다 라는 뜻
    • self-descriptive messages
      • 메세지는 스스로를 설명해야 한다.
      • 예시
        • GET / HTTP/1.1
          • 무언가 빠져있다.(목적지가 빠져있음)
          • 따라서 아랫줄에 목적지 host를 추가하여야 한다.
        • HTTP/1.1 200 OK [ {“op”:”remove”, “path”:”/a/b/c”}]
        • 이는 content-type이 빠져있다.! (Content-Type:application/json 추가)
        • 하지만 이것만으로도 명확하지 않다. 따라서 Content-type을 새로 만들어서 정의해야 한다.
    • hypermedia as the engine of application state(HATEOAS)

  • uniform interface가 필요한 이유는?

    • 서버와 클라이언트는 독립적으로 진화하기 때문이다
      • 서버가 기능이 바뀐다(ex : uri가 바뀌던, 등등) 이때 클라이언트가 바뀔 필요가 없기 때문이다.
      • 이것이 REST가 만들어지게 된 이유이다.

  • 웹은 보통 REST를 잘 만족한다

    • 웹 페이지를 변경했다고 웹 브라우저를 업데이트 안해도 됨.
    • 반대도 똑같음.
    • HTTP 명세가 바뀌어도 잘 동작함.
    • HTML 명세가 바뀌어도 잘 동작함.

❗ 그래서 REST의 정의는?

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

  • HTTP URI를 통해 Resource를 명시하고 HTTP Method를 통해 자원에 대한 CRUD를 적용하는 것을 의미한다.

    • 자원 기반의 구조 설계의 중심에 Resource가 있으며 Http Method를 통해 Resource를 처리하도록 설계된 아키텍처!
    • 웹 사이트의 이미지, 텍스트, DB내용 등의 모든 자원에 고유한 HTTP URI를 부여한다.
    • CRUD
      • Create -> POST
      • Read -> GET
      • Update -> PUT
      • Delete -> DELETE
      • HEAD -> HEAD
  • API란?
    • 데이터와 기능의 집합을 제공하여 프로그램 간 상호작용을 촉진하고 정보를 교환할 수 있게 하는 것.

❗ 장점과 단점

  • 장점

    • HTTP를 그대로 쓰므로 RSET를 위한 별도의 인프라가 필요없다.
    • HTTP 표준을 사용하는 모든 곳에서 사용이 가능하다.
    • REST API 자체의 메세지가 의미하는 바를 쉽게 파악할 수 있다.
    • 서버와 클라이언트의 역할을 명확히 분리한다

  • 단점

    • 표준이 없다.
    • 사용할 수 있는 메소드가 HTTP Method가 다이다.

❗ REST가 필요한 이유

  • 애플리케이션 분리 및 통합
  • 다양한 클라이언트

❗ REST 구성 요소

  1. 자원(URI)

    • 서버에 존재
    • 구별은 HTTP URI로
    • Client는 URI를 통해 자원을 지정하고 그에대한 조작을 Server에 요청하는 방식

  2. 행위(HTTP Method)

    • POST, GET, PUT, DELETE 등

  3. 표현

    • 조작을 요청받으면 서버는 이에대한 응답(Representation)을 보냄
    • JSON, XML, TEXT 등 여러 표현이 있다.
    • JSON이나 XML이 일반적

❗ 특징

  • 서버-클라이언트

    • 자원이 있는 곳이 server
    • 자원을 요청하는 놈이 Client
    • 의존성이 없어지는 것이 특징

  • Stateless

    • HTTP 프로토콜 자체가 무상태성이므로 따라간다.
      • 즉 Client의 context를 서버에 저장하지 않음.
    • 서버는 각각 요청이 서로 별개임을 인식함.
      • 이전 요청이 다음 요청처리에 연관이 크게 되지 않음.

  • Cacheable(캐시 처리)

    • HTTP의 특징 중인 캐시를 적용할 수 있음.
      • Last-Modified, E-Tag
    • 대량의 요청을 효율적으로 처리함.
    • 응답시간이 빨라지며 캐싱된 데이터는 트랜잭션이 발생하지 않아서 자원 이용률도 향상됨.

  • Layered System(계층화)

    • Server는 다중계층일 수 있다.
      • 서버의 앞단에 로드밸런싱 등을 추가하여 구조상의 유연성을 줄 수 있음.

  • Code-On-Demand(Optional)

    • 서버로부터 스크립트를 받아서 Client에서 실행할 수 있는것
    • 옵션

  • Uniform Interface(인터페이스 일관성)

    • Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행함.

❗ REST 설계 기본 규칙

  1. URI는 정보의 자원을 표현해야 함

    • resource는 동사보다 명사, 대문자보다는 소문자
    • 도큐먼트 이름으로는 단수 명사를 써야함
    • 컬렉션 이름으로는 복수 명사
    • 스토어 이름은 복수 명사

  2. 자원에 대한 행위는 HTTP Method로 표현한다.

    • URI에 HTTP Method가 들어가면 안됨.
    • 행위에 대한 동사표현이 들어가면 안됨
    • 변하는 부분은 유일한 값으로 대체함.
  3. 슬래시 구분자는 계층 관계를 나타내는 데 사용함
  4. 마지막 문자로 슬래시를 포함하지 않는다.
  5. 하이픈은 가독성을 높여준다
  6. 밑줄은 사용하지 않는다.
  7. 파일 확장자는 포함하지 않는다.

Leave a comment