Rest api를 사용하면서 개념을 제대로 잡아보질 않아서 이번에 프로젝트를 진행하면서 리펙토링 기간동안 공부해봤습니다.

그 전에는 Rest api는 통신 역할로 웹에서 데이터를 CRUD형식으로 사용하는 방법으로만 단순히 기억하고있었습니다. 그래서 이번계기로 틈틈히 rest가 무엇이고 rest api가 무엇인지 왜 쓰는지에 대해서 공부해보았습니다.

우선 REST가 무엇인지 그리고 장단점, REST API는 무엇인지 그것에대한 내용을 적어보겠습니다.

REST란?

• REST의 정의

  • 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미
  • 즉, 자원(resource)의 표현(representation)에 의한 상태 전달
    1. 자원의 표현
       • 자원 : 해당 소프트웨어가 관리하는 모든 것
         • 문서, 그림, 데이터, 해당 소프트웨어 자체 등
       • 자원의 표현 : 그 자원을 표현하기 위한 이름
         • DB의 학생 정보가 자원일 때, 'students'를 자원의 표현으로 정함.
    2. 상태(정보) 전달
       • 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다.
       • JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
  • 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
    • REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
    • REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나

• REST의 구체적인 개념

  • HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
    • Create : 데이터 생성(Post)
    • Read : 데이터 조회(Get)
    • Update : 데이터 수정(Put, Patch)
    • Delete : 데이터 삭제(Delete)
  • REST 구성 요소
    1. 자원(Resource) : HTTP URI
    2. 자원에 대한 행위(Verb) : HTTP Method
    3. 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load
  • REST의 장단점
    • 장점
      • HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출 할 필요가 없다
      • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함계 가져갈 수 있게 해준다.
      • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능
      • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장
      • REST API 메세지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악
      • 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화
      • 서버와 클라이언트의 역할을 명확하게 분리
    • 단점
      • 표준이 자체가 존재하지 않아 정의가 필요함
      • HTTP Method 형태가 제한적
      • 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구
      • 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많음.
        • PUT, DELETE를 사용하지 못하는 부분
        • pushState를 지원하지 않는 점

---

REST API란?

• API(Application Programming Interface)
  • 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것
• REST API의 정의
  • REST기반으로 서비스 API를 구현하는 것
  • 최근 OPEN API(공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.
• REST API의 특징
  • 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있음
  • REST는 HTTP 표준을 기반으로 구현

앞선 내용은 블로그를 참고하면 쓸 수 있는 내용이다. 하지만 정말 REST API의 정의는 이것일까?라는 의문이 들어서 유튜브로 한 우아한테코 학생이 한 설명을 듣게되었다.

REST API 간략 설명

요약하자면 아래의 내용들과 같다.

논문에따르면

하지만 이러한 설명은 REST API 창시자(Roy Fielding)가 말하길..

CRUD에대한 내용은 한 적이 없고 HTTP 메서드는 REST가 아니라 웹의 아키텍처 스타일의 일부다.

HTTP에서 정의한 방식대로만 잘 쓴다면 REST는 딱히 할 말이 없다...

Roy Fielding이 말하길 REST API란?

• REST 아키텍처 스타일에 부합하는 API

  1. Server-Client(서버-클라이언트 구조)

  2. Stateless(무상태)

  3. Cacheable(캐시 처리 기능)

  4. Layered System(계층화)

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

     1. 자원에 대한 식별(identification of resources)

        • 이름을 지닐 수 있는 모든 정보. 자원은 객체

        • 상태는 변화가능! -> 변하지 않는 식별자

        • URI를 통해 자원을 식별해야 한다.

     2. 표현을 통한 자원에 대한 조작(manipulation of resources through representations)

        • 표현 : 특정한 상태의 자원에 대한 표현

        • 클라이언트가 서버에 GET /user/1 HTTP/1.1를 보내면 자원의 현재 상태에 대한 표현을 서버에서 해준다.

        • 반면 자원의 기대되는 상대(이미지)를 POST하면 새로운 임시 자원을 생성하고 식별자를 할당

        • Representational State Transfer(표현된 (자원의)상태)

          • 자원의 현재 상태

          • 자원의 기대되는 상태

     3. 자기 서술적인 메세지(self-descriptive messages)

        • 메세지는 스스로에 대해 설명

        • 클라이언트와 서버 사이의 컴포넌트들은 메세지의 내용을 참고하여 적절한 작업 수행

        • Host 헤더에 도메인명 기재 필요

          • cf) HTTP/1.1부터 Host 헤더 필수화

        • 도메인명 정보의 필요성

          • 가상호스트 문제
            • 하나의 IP주소에 복수의 도메인명 존재 가능
            • IP 주소만으로는 요청 대상을 찾아낼 수 없음.

        • 캐쉬 관련 헤더를 통한 캐쉬 전략 지정

     4. HATEOAS(Hypermedia as the engine of application state)

        • 하이퍼미디어를 통한 앱 상태 변경
        • 위배 사례
          • 숨겨진 페이지, 경로가 존재가 존재하면 HATEOAS 위배
        • 프론트와 백엔드 사이에 일반적으로 JSON형태의 데이터를 주고받음
          • HATEOAS위배한 경우가 대다수임
          • 서버에 보낼 수 있는 요청들에 대한 정보를 Client에 보낼 수 있다면 위배되지않음

• REST API여야 하는가?

  • Uniform Interface 제약조건은 비효율적
  • 애플리케이션에 필요한 정보가 아니라, 표준화된 형식으로 데이터 전달
  • 상황에 따라 최적이 아닐 수 없음

• API 설계의 방향성

  1. 진짜 REST API 만들기(RESTful API)

  2. REST 스타일의 API 만들기(HTTP API)

     • REST 제약조건 부분적으로 준수
       • Ex) URI을 통한 자원 식별
     • HTTP 스펙 적절하게 활용
     • API 설계에 관한 컨벤션 참고

3. 다른 API 표준 선택하기(Graphql API)

   • URI를 통한 자원 식별 제약조건 위배
     • /graphql

---

그런 REST API로 괜찮은가?

우아한 테코에서 발표한 REST API를 보면서 추천해주는 영상

• 그런 REST API로 괜찮은가

이 블로그에서 내용들을 영상의 내용들을 정리해줌

• 그런 REST API로 괜찮은가

---

이 영상과 내용들을 읽으면서 data와 header부분의 쓰임들을 알게되었고 api에서 http api로 쓰이는 내용과 REST API로 쓰이는 부분들에서 다른 방식들을 보게되었습니다.아직까지는 내용들을 읽어봐도 잘 모르는 입문자이기때문에 계속해서 돌려보고 제가 쓴 코드는 어떤 API를 썻는가?라는 의문점으로 공부를 해야될 것 같습니다.