Skip to content

Ch03_RestAPI.md

Latest commit

 

History

History
67 lines (55 loc) · 5.76 KB

Ch03_RestAPI.md

File metadata and controls

67 lines (55 loc) · 5.76 KB

REST

REST (Representational State Transfer : 자원의 상태 전달) - 네트워크 아키텍처


아래 6가지 아키텍처를 잘 지켰을 때 RestAPI , Restful하다고 표현한다.

6가지 아키텍처

  1. Client,Server
    • 클라이언트와 서버가 서로 독립적으로 분리되어 있어야 한다.
    • 클라이언트와 서버가 한곳에 구성되어 있을 경우, 서로의 데이터가 밀접하게 연관되어 독립되지 못할 경우 Rest API를 잘 지키지 못한 경우이다.
  2. Stateless
    • 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다.
    • 예 ) 햄버거가게에 갈때 치즈버거에 콜라를 주문한다면 주문을 받은 클라이언트의 상태를 서버에 저장하지 말아야한다. 그렇기 때문에 "치즈버거 주세요" -> "치즈버거와 콜라주세요" 로 요청을 한다.
  3. Cache
    • 클라이언트는 서버의 응답을 Cache(임시 저장)할 수 있어야 한다.
    • 클라이언트가 Cache를 통해서 응답을 재사용할 수 있어야 하며, 이를 통해서 서버의 부하를 낮춘다.
    • 서버에서도 cache기능을 활용해서 중복된 요청에 저장된 데이터를 응답하기도 한다.
  4. 계층화 (Layred System)
    • 서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다양한 계층 형태로 구성이 가능해야 하며, 이를 확장할 수 있어야 한다.
  5. 인터페이스 일관성
    • 인테페이스의 일관성을 지키고, 아키텍처를 단순화시켜 작은 단위로 분리하여, 클라이언트,서버가 독립적으로 개선될 수 있어야 한다.
    • 서버가 바뀌더라도 클라이언트에 지장을 주지 않고 클라이언트가 바뀌더라도 서버에 영향을 주지 말아야 한다.
  6. Code on Demand(Optional)
    • 자바 애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로부터 클라이언트가 전달받아 코드를 실행할 수 있어야 한다.
    • 현재는 사용하지 않는 자바 애플릿, 사용하지 못하게 된 플래시, 가장 많이 사용하는 자바스크립트 (서버로부터 HTML,JS,CSS 파일을 가져와서 화면을 출력할 때 데이터를 보충하는 형태로 프론트엔드를 구축하는 형태)

인터페이스의 일관성

인터페이스의 일관성이 잘 지켜졌는지에 따라, REST를 잘 사용했는지 판단을 할 수 있다.


<판단 기준 4가지>

  1. 자원의 식별
    • 웹기반의 REST에서는 리소스 접근을 할때 URI를 사용합니다.
    • URI에 자원을 식별할 수 있는 정보가 담겨있어야 한다.
    • -> https://foo.co.kr/user/100
    • 예를 들어 위와 같은 URI 하위에 user/100이란 정보가 있다면 Resource는 user, 식별자는 100이된다. 즉 100번째 user를 식별한다.
  2. 메시지를 통한 리소스 조작이 가능
    • Web에서는 다양한 방식으로 데이터를 전달 할 수 있습니다.
    • 그 중에서 가장 많이 사용하는 방식은 HTML,XML,JSON,TEXT 등이 있다.
    • 이 중에서 어떠한 타입의 데이터인지를 알려주기 위해서 HTTP Header 부분에 contetn-type의 Value을 통해서 데이터의 타입(예시 - json/utf-8)을 지정해 줄 수 있습니다.
    • 또한 리소스 조작을 웨해서 데이터 전체를 전달 하지 않고 이를 메시지로 전달합니다.
    • -> 예를들어 서버의 User라는 DB에 컬럼이름을 number로 결정했고 Client와 number라는 필드로 주고받고 있을 때, 후에 서버에서 resource 변경으로 number를 phonenumber로 바꾸게 된다면 Client는 데이터 처리를 하지 못하고 에러가 난다.
    • ->이것은 데이터 전체를 전달했기 때문에 발생한 문제, 이 부분을 방지하기 위해서 별도의 메시지 형태로 데이터를 주고받으며 일정 규약의 API 스펙을 기반으로 통신하고 서버에서 클라이언트에 메시지를 통해 전달해야 한다.
    • ->이는 서버와 클라이언트의 독립적인 형태가 아니므로 독립적인 확장이 불가능해진다.
    • 즉, 메시지를 통하 리소스 조작이 가능해야 되고 데이터를 전체로 전달하지 않아야 한다!
  3. 자기 서술적 메시지를 작성할 수 있어야 한다.
    • 요청하는 데이터가 어떻게 처리되어져야 하는지 충분한 데이터를 포함할 수 있어야 한다.
    • HTTP 기반의 REST에서는 HTTP Method와 Header의 정보, URI의 포함된 정보로 표현할 수 있다.
      • GET : https://foo.co.kr/user/100 , 사용자의 정보 요청
      • POST : https://foo.co.kr/user , 사용자 정보생성
      • PUT : https://foo.co.kr/user , 사용자 정보 생성 및 수정
      • DELETE : https://foo.co.kr/user/100 , 사용자 정보 삭제
      • 그 외에 담지 못한 정보들은 URI의 메시지를 통하여 표현한다.
  4. 애플리케이션 상태에 대한 엔진으로써 하이퍼미디어
    • REST API를 개발할 때 단순히 한가지 Client 요청에 대한 데이터의 응답만 해주는 것이 아닌 그외에 서버가 가지고 있는 관련된 리소스에 대한 Link 정보까지 같이 포함되어져야 한다.
    • 이러한 조건들을 잘 갖춘 경우 REST Ful 하다고 표현하고 이를 REST API라고 부른다.
    • 현업에서는 잘 사용하지 않는 부분..
      • Client 개발을 할때 서버의 API 스펙에 따라 데이터 class를 생성하여 Mapping을 하게 되는데 주소 정보까지 매핑을 할때 실제로 서버로부터 받아오는 데이터 외에 불필요한 데이터 정보도 작성해야하기 때문에

이것은 규약이며, 반드시 이렇게 개발해야 한다라기 보다 REST API를 개발한다고 할때 이것들을 지켜서 REST Ful 한 개발을 하는 것이다.