[네트워크] REST API

Geunhyung Pyun·2024년 2월 22일

개발자라는 것을 하면서 처음에는 많이 듣고 공부했던 기본적인 개념이나 점차 시간이 지날수록 계속해서 까먹게 되는 개념이 있다.

그 중 하나가 바로 REST 에 대한 개념이다. 이것이 왜 나타났는지, 무엇인지 등 가물가물해지니 정리를 하고자 한다.

배경


인터넷이 생겨나고 데이터를 주고 받는 일들이 많아지게 된다. 기존에는 주고받는 데이터의 형식이 웹브라우저마다 os마다 달랐겠지만 점차 플랫폼에 따라 제약을 받지 않고 바로 그 자리에서 알아볼 수 있는 형태의 데이터 통신이 필요하게 된다.

이전에는 서버와 클라이언트가 데이터를 주고받았을 때 SOAP를 이용하였다. 네트워크 망을 새롭게 하기는 귀찮고 비용도 들기에 기존에 주고받았던 HTML 과 HTTP 를 이용하면 되지 않을까에서 출발하였다. 그래서 HTML 에서 확장된 문법인 XML 을 이용한 통신인 SOAP 가 사용되었다.

REST 이와 비슷한 시기에 탄생하였다. 웹 설계의 우수성에 비해 제대로 사용되지 않은 모습에 안타까워한 Roy T.Fielding 이 웹의 장점을 최대한 활용할 수 있도록 만든 아키텍쳐로 초기에는 큰 관심을 받지 못하였다.
그러나, XML 메시징이 속도를 저하시키고 더 무겁게 만드는 점, 빌트인 보인 및 트랜잭션 컴플라이언스처럼 특정 요구 사항이 있다는 점 등 SOAP의 규정된 프로토콜보다 사용하기 쉽기에 REST 사용이 급증하게 되었다.

개요


그럼 이 친구는 무엇일까?

  • Representational State Transfer 의 약자.
  • API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처
  • 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
  • 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어짐.
  • 세 가지의 구성요소로 이루어져 있다.
    • 자원(Resource): URI
      • 모든 자원에 고유한 ID가 존재하고 자원은 서버에 존재
      • 클라이언트는 URI를 이용해서 자원을 지정하고 해당 자원의 상태에 대한 조작을 서버에 요청
    • 행위(Verb): HTTP Method
      • HTTP 프로토콜의 Method
      • GET, POST, PUT, DELETE 메서드를 제공한다.
    • 표현(Represtations)
      • 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버는 이에 대한 적절한 응답을 보낸다.
      • REST 에서 하나의 자원은 여러 형태(JSON, XML, Text, RSS 등) 로 나타낼 수 있다.
      • 일반적으로는 JSON, XML 을 통해 데이터를 주고 받는 것이 일반적이다.

특징


여섯 개의 특징이 있다.

  1. 클라이언트 - 서버 구조

    • 정보를 요청하는 쪽이 클라이언트, 정보를 제공하는 쪽이 서버이다.
      • 클라이언트: 사용자 인증이나 context 등을 직접 관ㄹ하고 책임진다.
      • 서버: API를 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
    • 아키텍처를 단순화시키고 작은 단위로 분리함으로써 독립적으로 개선될 수 있도록 해준다.
  2. 무상태(stateless)

    • HTTP 를 이용하기에 무상태성을 갖는다.
    • 클라이언트는 임의의 순서로 리소스를 요청할 수 있고 모든 요청은 무상태거나 다른 요청과 분리된다.
      • 즉, 세션과 쿠키와 같은 정보를 신경쓰지 않아도 되어 구현이 단순해진다.
    • 서버는 각각의 요청을 완전히 별개의 요청으로 인식하고 처리한다.
      • 각 API 서버는 클라이언트의 요청만을 단순 처리
      • 서버의 처리 방식에 일관성을 부여하고 부담이 줄어들고 서비스의 자유도가 높아진다.
  3. 계층화 시스템

    • 클라이언트와 서버 사이에 중간 서버를 자유롭게 둘 수 있다.
    • 프록시 서버, 보안 서버 등 자유도가 높다.
  4. 캐시 처리 가능

    • 웹 표준 HTTP 프로토콜을 사용하기에 웹에서 사용하는 기존 인프라를 그대로 사용가능하다.
      • 서버 응답 시간을 개선하기 위해 클라이언트 혹은 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원
    • 응답 시간이 빨라지고 서버 자원 이용률이나 성능 등을 향상시킬 수 있다.
  5. On-demand 코드

    • 서버는 SW 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다.
    • 옵션 사항이다.
  6. 인터페이스 일관성(Uniform Interface)

    • URI 로 지정한 자원에 대한 동작을 통일되고 한정적인 인터페이스로 수행하여야 한다.
    • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

규칙


  • 슬래시(/)는 계층 관계를 나타내는데 사용. URI 마지막 문자로는 포함하지는 않는다.
  • 밑줄(_)은 URI에 사용하지 않는다.
  • 파일 확장자는 URI에 포함하지 않는다.

장단점


장점

  • HTTP 프로토콜의 인프라를 그대로 사용하기에 별도의 인프라를 구축할 필요가 없다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서는 사용 가능하다.
  • 하이퍼미디어의 기본을 충실히 지키고 범용성 보장한다.
  • 서버와 클라이언트의 역할을 명확하게 분리한다.
  • REST API 메시지가 의도하는 바를 명확하게 나타내므로 쉽게 의도가 파악된다.

단점

  • 표준이 정의되어 있지 않아 사용자에 따라 다르다.
  • HTTP method 형태도 제한적이다.(4가지)
  • 구형 브라우저가 제대로 지원해주지 못하는 부분이 존재한다. (put, delete의 사용 불가 등)
profile
개발자를 원하는 사람.

0개의 댓글