ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Network] REST API
    CS/Network 2022. 2. 17. 15:14

    REST API

    출처: http://www.incodom.kr/REST

    API(Application Programming Interface)

    API는 애플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜 세트로, 컴퓨터나 시스템과 상호 작용하여 정보를 검색하거나 기능을 수행하고자 할 때, 사용자가 원하는 것을 시스템에 전달할 수 있게 지원하여 시스템이 이 요청을 이해하고 이행하도록 한다. 즉, API는 클라이언트와 클라이언트가 얻으려 하는 리소스 사이의 조정자 역할을 한다.

    예를 들어, 날씨 서비스용 API에서는 사용자가 우편번호를 제공하고 생산자는 (최고 기온, 최저 기온)으로 구성된 응답을 하도록 지정한다.

    REST API

    REST API는 REST 아키텍처의 제약 조건을 준수하는 API를 말한다.

     

    REST

    정의

    REST는 'Representational State Transfer'의 약자로, 프로토콜이나 표준이 아닌 아키텍처 원칙 세트이다. API 개발자는 REST를 다양한 방식으로 구현할 수 있다. REST API를 통해 요청이 수행될 때 REST API는 리소스 상태(State)에 대한 표현(Representation)을 요청자에게 전송(Transfer)한다.

    자원의 표현(Reprensentation)JSON, XML, HTML, XLT 또는 일반 텍스트를 통해 몇 가지 형식으로 전송된다. 이때 자원은 문서, 이미지, DB 등 해당 소프트웨어가 관리하는 모든 것을 말한다.

    다시 말하면, REST는

    1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고
    2. HTTP Method(POST, GET, PUT, DELETE)를 통해 자원에 대한 CRUD Operation을 적용하는 것

    즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 리소스가 있고, HTTP 메서드를 통해 리소스를 처리하도록 설계된 아키텍처를 의미한다.

    구성 요소

    자원(Resource): URI

    • 모든 자원은 고유한 Identify가 존재하고, 이 자원은 서버에 존재한다.
    • 자원을 구별하는 Identifier는 HTTP URI다.
    • 클라이언트는 URI를 통해 자원을 지정하고 해당 자원의 상태에 대한 조작을 서버에 요청한다.

    행위(Verb): HTTP Method

    • HTTP의 Method(GET, POST, PUT, DELETE)를 사용한다.

    표현(Representation)

    • 클라이언트가 자원의 상태에 대한 조작을 요청하면, 서버는 이에 적절한 응답(Representation)을 보낸다.
    • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.

    REST의 특징

    Client-Server Architecture

    • 클라이언트, 서버 및 리소스로 구성되어있으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍쳐

    Stateless

    • HTTP는 Stateelss 프로토콜이기 때문에 HTTP를 통해 관리되는 REST 역시 Stateless를 갖는다.
    • 요청 간에 클라이언트 정보(context)가 서버에 저장되지 않는다.
      • 서버는 클라이언트 정보를 신경쓰지 않아도 되기 때문에 단순해진다.
    • 각 요청이 분리되어 있고, 서로 연결되지 않는다.
      • 각 API 서버는 단순하게 클라이언트의 요청만을 처리한다.
      • 이전 요청이 다음 요청에 연관되어서는 안된다.
      • 서버의 처리 방식에 일관성을 부여하여 부담이 줄어들고 서비스의 자유도가 높아진다.

    Cacheable

    • HTTP를 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능을 그대로 활용할 수 있다.
    • 캐시 사용을 통해 클라이언트-서버 간의 상호 작용을 최소화하여 응답시간이 빨라지고, 성능을 향상시킬 수 있다.

    Layered System

    • 요청된 정보를 검색하는 데 관련된 서버(보안, 로드밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화할 수 있다.
      • API 서버는 비즈니스 로직만을 수행하고 보안, 로드밸런싱, 암호화, 사용자 인증의 서버를 추가하여 구조상의 유연성과 확장성, 보안성을 향상시킬 수 있다.

    Uniform Interface

    • URI로 지정한 리소스에 대한 조작을 통일된 인터페이스로 수행한다.
    • HTTP를 따르는 모든 플랫폼에서 사용 가능하다.
      • 특정 언어나 기술에 종속되지 않는다.

    Code-On-Demand(Optional)

    • 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있다.

    REST의 장단점

    장점

    • HTTP의 인프라를 그대로 사용하기 때문에 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
    • HTTP를 따르는 모든 플랫폼에서 사용 가능하다.
    • REST API 메시지를 읽는 것만으로도 메시지가 의도하는 바를 명확하게 파악할 수 있다.
    • Stateless한 특징으로 서버와 클라이언트의 역할이 명확하게 분리된다.

    단점

    • HTTP 메서드 형태가 제한적이다.
    • 표준이 존재하지 않는다.
      • 이로 인해 관리의 어렵고, API 디자인 가이드가 존재하지 않는다.

    Reference

    https://www.redhat.com/ko/topics/api/what-is-a-rest-api

    https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

    https://blog.metafor.kr/165

    https://wallees.wordpress.com/2018/04/19/rest-api-%EC%9E%A5%EB%8B%A8%EC%A0%90/

    댓글

Designed by Tistory.