[Web] REST, REST API?

K·2023년 3월 23일
0


REST

1. 개념

REpresentational State Transfer 의 약자

  • WEB과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식,
    리소스 지향 아키텍처
  • 자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것
    • 자원(resource)의 표현(representation)에 의한 상태 전달을 뜻함
  • 웹에 존재하는 모든 자원(이미지, 동영상, DB자원)에 고유한 URI를 부여해 활용하는 것으로, 자원에 대한 주소를 지정하는 방법론을 의미
  • REST 형식을 따르는 시스템을 RESTful 하다고 함
    ※ RESTful 이란
      REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful 하다고 할 수 있음
      모든 CRUD 기능을 POST로 처리하는 API 혹은 URI 규칙을 올바르게 지키지 않는 API는
      REST API를 사용하였지만 RESTful 하지 못한 시스템이라 할 수 있다
  • HTTP URI (Uniform Resource Identifier)를 통해 자원 (Resource)을 명시하고 HTTP Method (POST, GET, PUT, DELETE, PATCH 등)를 통해 해당 자원 (URI)에 대한 CRUD Operation 을 적용하는 것을 의미
    ※ CRUD operation 이란
     CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 
     Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로 
     REST에서의 CRUD Operation 동작 예시는 이하와 같음
       
       Create : 데이터 생성(POST)
       Read   : 데이터 조회(GET)
       Update : 데이터 수정(PUT, PATCH)
       Delete : 데이터 삭제(DELETE)

2. REST 의 구성요소

REST는 다음의 3가지로 구성

  1. 자원 (Resource) - URI

    • 모든 자원에는 고유한 ID가 존재, 이 자원은 Server에 존재
    • 자원의 식별은 HTTP URI
  2. 자원에 대한 행위 (Verb) - HTTP Method

    • HTTP Method를 통해 CRUD 적용
      • HTTP Method Operation 설명
        POST Create 데이터 조회, URI가 가진 정보를 검색하기 위해 서버에 요청
        GET Read 데이터 생성, 클라이언트에서 서버로 전달하려는 정보를 보냄
        PUT Update 데이터 수정, 데이터 전체를 수정
        PATCH Update 데이터 수정, 데이터 일부만 수정
        DELETE Delete 데이터 삭제, (안전성 문제로 대부분 서버에서 비활성화)
  3. 표현 (Representation of Resource)

    • Client와 Server 간의 데이터를 주고받는 형태로 JSON, XML, TEXT 등 HTTP 헤더에 지정된 Content-Type 중의 하나

3. REST 의 특징

  1. Server-Client 구조

    • Server는 API 제공, 비즈니스 로직 처리 및 저장에 대한 책임
    • Client는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 책임
    • 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됨
  2. 무상태(Stateless)

    • HTTP는 Stateless 프로토콜, REST 역시 무상태성을 가짐,
      클라이언트의 Context를 서버에 저장하지 않음 → 작업을 위한 상태정보를 따로 저장 & 관리하지 않음
    • 세션 및 쿠키를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됨, 이에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 단순한 구현이 가능
  3. 캐시 처리 가능(Cachealble)

    • HTTP 프로토콜을 그대로 사용하므로, WEB에서 사용하는 기존의 인프라를 그대로 활용 가능 → HTTP가 갖는 캐싱 기능 적용가능
    • 대량의 요청을 효율적으로 처리가능
  4. 계층화(Layered System)

    • API 서버는 순수 비즈니스 로직을 수행하고 그 앞단에 사용자 인증, 암호화,
      로드밸런싱 등을 수행하는 계층을 추가하여 구조상의 유연성을 가짐
    • Proxy, Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있음
    • Client는 Server와 직접 통신하는지, 중간 서버와 통신하는지는 알 수 없음
  5. 인터페이스 일관성(Uniform Interface)

    • URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행
      HTTP 표준에만 따른다면 모든 플랫폼에 사용가능, 느슨한 결함 형태를 가짐
      → 특정언어나 기술에 종속되지 않음
  6. 자체 표현 구조

    • 동사(Method) + 명사(URI)로 이루어져있으며 어떤 메소드에 무슨 행위를 하는지 알 수 있으며
      REST API 자체가 매우 쉬워서 API 메세지 자체만 보고도 API 이해가능

4. REST 의 장점 및 단점

  • 장점
    • 쉬운 사용
      • HTTP 프로토콜 인프라를 그대로 사용하므로 별도의 인프라를 구축할 필요가 없음
    • 클라이언트-서버 역할의 명확한 분리
      • REST의 특징이 Stateless에 따라 서버는 클라이언트의 Context를 유지할 필요가 없음
    • 특정 데이터 표현 사용가능
      • 헤더 부분에 URI 처리 메소드를 명시하고 필요한 실제 데이터를 ‘Body’에 표현할 수 있도록 분리, 이에 JSON, XML 등 원하는 Representation 언어로 사용 가능
  • 단점
    • 표준 자체가 존재하지 않음
      • REST는 설계 가이드일 뿐 표준 자체가 존재하지 않음, 정의가 필요
    • HTTP Method의 한계
      • HTTP Method 형태가 제한적

REST API

REST API 란? REST의 원리를 따르는 API를 의미
REST API 를 올바르게 설계하기 위해서는 지켜야 하는 몇가지 규칙이 있음, 이하 규칙을 소개

참고) API (Application Programming Interface) 란?
애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트

REST API 설계 예시

  1. URI 는 동사보다 명사를, 대문자보다는 소문자를 사용
    (×) http://example.com/Running/
    (○) http://example.com/run/

  2. 마지막에 슬래시(/)를 포함하지 않음
    (×) http://example.com/Running/
    (○) http://example.com/run/

  3. 언더바 대신 하이픈을 사용
    (×) http://example.com/test_blog
    (○) http://example.com/test-blog

  4. 파일확장자는 URI 에 포함하지 않음
    (×) http://example.com/photo.jpg
    (○) http://example.com/photo

  5. 행위를 포함하지 않음
    (×) http://example.com/delete-post/1
    (○) http://example.com/post/1


Reference


profile
Luck favors the prepared

0개의 댓글