07. 기술면접 - 네트워크 - REST와 RESTful의 개념

공부목적으로 다른 블로그의 글을 그대로 따라치면서 작성되었습니다. 저작권 문제 시, 비공개 처리하겠습니다

REST는 표현 상태 전송 을 나타냅니다. API(응용 프로그래밍 인터페이스)가 작동하는 방식을 설정하는 제약 조건 집합입니다. API가 RESTful이면 API가 REST 아키텍처를 준수한다는 의미입니다. 간단히 말해서 API에 관한 한 REST와 RESTful 사이에는 차이가 없습니다. REST는 제약 조건의 집합입니다. RESTful은 이러한 제약 조건을 준수하는 API를 나타냅니다. 웹 서비스, 응용 프로그램 및 소프트웨어에서 사용할 수 있습니다 .

 

REST(Representational State Transfer) 란

  - REST 의 정의
    - Representational State Transfer (대표적인 상태 전달)의 약자
    - 월드 와이드 웹(www)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
        - REST 는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다
        - REST는 네트워크 상에서 Client 와 Server 사이의 통신 방식 중 하나이다

  - 구체적인 개념
      - HTTP URI (Uniform Resource Identifier) 를 통해 자원 (Resource)을 명시하고, HTTP Method(Post, Get, Put, Delete) 를 통해 해당 자원에 대한 CRUD Operation 을 적용하는 것을 의미한다.
      - 즉, REST 는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource 가 있고, HTTP Method 를 통해 Resource 를 처리하도록 설계된 아키텍처를 의미한다
      - 웹 사이트의 이미지, 텍스트 DB 내용 등의 모든 자원에 고유한 ID 인 HTTP URI 를 부여한다

  - REST 장단점
    - 장점
      - 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화 해준다
      - Hypermedia API 의 기본을 충실히 지키면서 범용성을 보장한다
      - HTTP 프로토콜 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
    - 단점
      - 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URI 보다 Header 값이 어렵게 느껴짐
      - 구형 브라우저가 아직 제데로 지원해주지 못하는 부분이 존재한다
        -  PUT, DELETE 를 사용하지 못하는 점 (form 에 경우 <input type="hidden" name="_method" /> 로 줄 수 있다
        -  pushState 를 지원하지 않는 점 ( history.pushState - 뒤로가기 )
          - URI 를 통한 ServerSide Rendering 방식을 이용하게 된다면
            - 메인 페이지 -> 보드 1 페이지 -> 보드 5 페이지 클릭 -> 뒤로가기 -> 보드 1 페이지
          - REST 방식을 이용하게 된다면
            - 메인 페이지 -> 보드 1 페이지 -> 보드 5 페이지 클릭 -> 뒤로가기 -> 메인 페이지
       - REST 특징
         - Server-Client(서버 클라이언트 구조)
         - Stateless (무상태성)
           (cookie 를 이용해 session 을 서버에 저장했다면, rest 는 header 에 token 을 넣어 인증하고 세션을 저장하지 않는다)
         - Cacheable(캐시 처리 가능)

이미지 출처 - 나

HTTP 캐쉬로 API 속도 올리기

 

- REST 가 필요한 이유
  - 애플리케이션 분리 및 통합 (MSA = Micro Soft Service Application) 
  - 다양한 클라이언트의 등장
  - 즉, 최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다
  - MSA (Micro Service Application) 분산 서비스와 관련되어있다 ( api call 을 통한 데이터 처리 )

- REST 구성 요소
  A. 자원 (Resource) URI
    - 모든 자원에 고유한 id 가 존재하고, 이 자원은 Server 에 존재한다
    - 자원을 구별하는 id 는 'localhost:8080/user/:userId' 와 같은 HTTP URI 이다
    - Client 는 URI 를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server 에 요청한다

  B. 행위 (Verb) : Http Method
     - HTTP 프로토콜의 Method 를 사용한다
     - HTTP 프로토콜은 GET, POST, PUT, DELETE, HEAD 와 같은 메서드를 제공한다

  C. 표현 (Representation of Resource)
      - Client 가 자원의 상태(정보)에 대한 조작을 요청하면 Server 는 이에 적절한 응답표현(Representation) 을 보낸다
      - REST 에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation 으로 나타내어 질 수 있다
      - 옛날에는 XML 이였지만 현대에는 JSON 으로 표현하고 있다

  - REST 의 특징
    a. Server-Client (서버, 클라이언트 구조)
    b. Stateless (무상태성)
    c. Cacheable (캐시 처리 가능)
    d. Layered System (계층화)
    e. Code On Demand (option)
    f. Uniform Interface (인터페이스 일관성)

REST API (Representational State Transfer Application Programming Interface)

- API 는 해당 어플리케이션을 제어할 수 있게 해주는 중간 인터페이스(연결점입니다)
- 예를들어 키보드라는 인터페이스를 통해 하드웨어어 입력을 해주는 기능을 해주는 것과 같습니다
- 영화 조회 서비스 API 를 통해 특정 명령만 내리면 해당 어플리케이션이 그에 맞는 기능을 수행줍니다

- 정의
  - REST 를 기반으로 서비스 API 를 구현한 것
  - 최근 OpenAPI(누구나 사용할 수 있도록 공개된 API: 구글 맵, 공공 데이터 등), 마이크로 서비스(하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처) 등을 제공하는 업체 대부분은 REST API를 제공한다.

- 특징
  - REST 기반으로 시스템을 분산해 확장성과 재사용을 높여 유지보수 및 운용을 편리하게 할 수 있다
  - REST 는 HTTP 표준을 기반으로 구현하므로, HTTP 를 지원하는 프로그래밍언어로 클라이언트, 서버를 구현할 수 있다

- 기본 설계 규칙
  A. URI는 자원(Resource) 를 표현해야 한다
     1. resource 는 명사
     2. 소문자 복수형
     3. GET /members/1
  B. 자원에 대한 행위는 HTTP Method (GET, PUT, PATCH, DELETE, POST 등)으로 표현한다
     1. URI 에 HTTP Method 가 들어가면 안된다
       - GET /members/delete/1 -> DELETE /members/1
     2. 어떤 행위(Behavior)나 행동(Action) 에 관해서 동사 표현이 들어가면 안된다
       - GET /members/insert/2 -> POST /members/2
       - GET /members/show/1 -> GET /members/1

- REST API 설계 규칙
  - 슬래시 구분자(/) 는 계층 관계를 나타내는데 사용된다
  - URI 마지막 문자로 슬래시(/) 를 포함하지 않는다
  - 대소문자 구분으로서 kebab case 형식을 사용한다 (team-board)
  - 밑줄(_ )은 URI에 사용하지 않는다.
    - 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
   - URI 경로에는 소문자가 적합하다.
     -URI 경로에 대문자 사용은 피하도록 한다. RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
    - 파일확장자는 URI에 포함하지 않는다.
       - REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
       - Accept header를 사용한다.
       - Ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
       - Ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)
  - 리소스 간에는 연관 관계가 있는 경우
    - /리소스명/리소스 ID/관계가 있는 다른 리소스명
    - Ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)
  - :id는 하나의 특정 resource를 나타내는 고유값
    - Ex) student를 생성하는 route: POST /students
    - Ex) id=12인 student를 삭제하는 route: DELETE /students/12

 

RESTful

• RESTful의 개념
  • RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
    • 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
  • RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
• RESTful의 목적
  • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
  • RESTful API를 구현하는 근본적인 목적이 퍼포먼스 향상에 있는게 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는게 주 동기이니, 퍼포먼스가 중요한 상황에서는 굳이 RESTful API를 구현하실 필요는 없습니다.
• RESTful 하지 못한 경우
  • Ex1) CRUD 기능을 모두 POST로만 처리하는 API
  • Ex2) route에 resource, id 외의 정보가 들어가는 경우(/students/updateName)