REST에 대해 알아보자 🤔

0

공통

목록 보기
4/9
post-thumbnail

참고:

REST 소개

REST(REpresentational State Transfer)란, "웹에 존재하는 모든 자원(이미지, 동영상, DB 자원)에 고유한 URI를 부여해 활용"하는 것으로, 자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미한다고 한다. 따라서 RESTful API는 REST 특징을 지키면서 API를 제공하는 것을 의미한다.
Roy Fielding에 의해 처음 쓰인 용어(필딩 논문)로써 일반적인 웹(혹은 유사한)을 만들기 위한 제약 조건들을 나열하여 제안한 일종의 디자인 가이드이다.


" 현재 아키텍처가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처를 소개한 것이 Representational state transfer(REST) 이다."


REST의 구성요소

  1. 자원 = URI
  • 어플리케이션을 구성하는 자원에 특정한 ID를 부여하고, 서버가 그 자원을 가지고 있다.
  • 이 자원의 ID를 HTTP URI으로 식별한다.
  • Client가 특정 자원에 대한 요청이 필요할 시 URI를 통해 접근하도록 한다.
  1. 행위 = HTTP METHOD
  • 자원에 대한 특정한 행위를 HTTP METHOD를 통해 규명한다.
  • C : 생성을 의미하는 행위에는 POST
  • R : 조회를 할 시 GET
  • U : 자원에 대한 수정이 필요할 때 PUT & PATCH
  • D : 해당 자원을 삭제할 때 DELETE
  1. 표현
  • Client가 자원에 대한 요청을 보낼 시, SERVER는 그것에 대한 적절한 응답을 보낸다.
  • 요청이 성공적으로 실행 될시 status 200 code를 보내고, 실패시 그에 합당한 status code를 보내면 된다. 더 자세한 상태코드 내용은 HTTP 상태 코드 에서 확인 가능하다.
  • REST에서는 자원을 표현하는데, JSON,XML과 같은 여러가지 표현으로 나타내질 수 있다.

REST의 특징

  1. SERVER와 Client 구조
  • 자원을 요청하는 Client는 사용자 인증 및 Context 등을 직접 관리한다.
  • 서버는 API를 제공하여, 자원을 처리하는 로직을 처리 및 자원 저장을 맡는다.
  • 두 그룹이 독립적으로 엄무를 수행하여, 보다 각자의 역할에 집중할 수 있다.
  1. Stateless
  • 서버는 각각의 요청을 별개의 것으로 인식하고 처리해야된다. 이전 요청과 다음 요청 사이에 관계가 있어서는 안된다. 그래서 REST API는 세션정보나 쿠키정보를 활용하여 작업을 위한 상태정보를 저장 및 관리하지 않습니다.
  • 불필요한 정보를 관리하지 않으므로 구현이 단순하며, 무상탱성은 서버의 처리방식에 일관성을 부여하여, 부담을 줄일 수 있다.
  1. Cacheable
  • HTTP를 그대로 사용하기 때문에, 캐싱 기능을 적용할 수 있다.
  • Last-Modified Tag 또는 E-Tag를 이용하여 캐싱을 한다.
  • 대량의 요청을 효율적으로 처리 할 수 있다.

    캐쉬란?
    캐쉬란 client가 요청하는 html, image, js, css등에 대해 첫 요청 시에 파일을 내려받아 특정 위치에 복사본을 저장(USING SPACE)하고, 이후 동일한 URL의 Resource요청은 다시 내려 받지 않고 내부에 저장한 파일을 사용하여 더 빠르게 서비스(SAVE TIME)하기 위한 것입니다. 서버를 통해 내려 받는 양이 적어지니 응답 시간이 감소하고 네트워크 트레픽이 감소되니 server와 client 모두가 win-win할 수 있는 최고의 tradeoff 인 셈입니다.

  1. Layered System
  • REST 서버는 다중 계층으로 구성될 수 있다.
  • API 서버는 순수 비즈니스 요청만 실행하고, 그 앞단에 보안, 로드밸런싱, 암화화, 사용자인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
  • 로드밸런싱이 무엇인지 모르시면 로드밸런싱 간단 설명 이 블로그의 글이 잘 되어있어서 읽는것을 추천한다.
  • PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.

프록시(Proxy)란 '대리'라는 의미로,네트워크 기술에서는 프로토콜에 있어서 대리 응답 등에서 친숙한 개념입니다. 보안 분야에서는 주로 보안상의 이유로 직접 통신할 수 없는 두 점 사이에서 통신을 할 경우 그 상이에 있어서 중계기로서 대리로 통신을 수행하는 기능을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부릅니다.

게이트웨이는 ‘관문’이나 ‘출입구’라는 의미로 다양한 분야에서 일반적으로 사용되는 용어입니다. 컴퓨터 네트워크에서의 게이트웨이는 현재 사용자가 위치한 네트워크에서 다른 네트워크로 이동하기 위해 반드시 거쳐야 하는 거점을 의미합니다. 자동차 고속도로로 진입하기 위해 통과하는 톨게이트와 유사한 개념입니다.
두 컴퓨터가 네트워크 상에서 서로 연결되려면 동일한 통신 프로토콜을 사용해야 합니다. 따라서 프로토콜이 다른 네트워크 상의 컴퓨터와 통신하려면 두 프로토콜을 적절히 변환해 주는 변환기가 필요한데, 게이트웨이가 바로 이러한 변환기 역할을 합니다. 한국인과 미국인 사이에 원활한 의사소통을 위해 통역사를 두는 것과 동일합니다.

  1. Code-on-Demand (선택적)
  • server로부터 스크립트를 받아서 Client에서 실행한다. (반드시 충족할 필요는 없다.)
  1. Uniform Interface
  • URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

정리

  • 서버와 클라이언트의 역할을 독립적으로 수행하여, 각자의 역할에 더 집중할 수 있다.
  • URI로 자원을 식별하고 HTTP METHOD로 자원에 수행되는 일관적인 인터페이스이기 때문에, 이해하기 쉽고 의도를 파악할 수 있다.
  • HTTP를 기반의 플랫폼이기만 하면 적용이 가능하다.
  • 서비스 디자인에서 발생할 수 있는 문제를 최소화 할 수 있다.

하지만 다른 방향으로 생각하면 이 아키텍쳐는 제한적인 HTTP METHOD 및 표준이 존재하지 않아 다소 난해할 수 있다.

profile
# 개발 # 컴퓨터공학

0개의 댓글