REST API란?

    반응형

    0. API란?

    • API는 Application Programming Interface의 약쟈로, 한 프로그램에서 다른 프로그램으로 데이터를 주고 받기 위한 방법입니다. (방법이란, 결국 코드임!)
    • 웹서버에 어떤 상품의 정보를 보여주는 코드가 있다고 가정했을 때, 유저가 어떻게 이 코드를 실행시킬 수 있을까요? 바로 API를 통해서 실행시킬 수 있습니다.

    위의 코드가 상품(product)의 정보를 데이터베이스에서 꺼내서 보여주는 코드라고 가정해봅시다. 유저가 이 코드를 실행시키기 위해서는 API 코드가 필요합니다.

    nodo.js에서 작성한 API 코드

    app.get() 부분이 API 코드에 해당하는 부분입니다. 사용자가 https://example/detail/:10을 요청하면 상품을 정보를 보여주는 코드가 실행되는 것이지요!

    즉, API는 주문을 할 수 있게 해주는 메뉴판에 해당한다고 생각하면 됩니다. 메뉴판없이 주문을 할 수는 없습니다. API로 요청을 하는 것이 메뉴판에 있는 메뉴 안에서 주문을 하는 것에 해당하고 요청을 내려받는 것이 음식이 서빙받는 것에 해당한다고 볼 수 있습니다.

    모든 프로그램은 API를 가질 수 있습니다. 예를 들어 운영체제인 Windows도 프로그램입니다. 따라서 Windows API를 쓰면 윈도우 운영체제 기능들을 사용할 수 있습니다. 데이터베이스 관리프로그램 API를 사용하면 데이터베이스의 입출력 등의 기능들을 사용할 수 있겠지요. 

    • API를 개발할 때는 다음 3가지가 필요합니다. 
      1. 어떤 요청을 할 것인가?(method): 데이터를 달라고 할것인지(GET), 데이터를 보낼 것인지(POST)를 명시해야 합니다.
      2. 어떤 데이터를 요청할 것인가?(endpoint)
      3. 부가적으로 실어보낼 정보(query parameter)

     

    1. REST API란?

    REST API는 API를 잘 만들 수 있는 방법 중 하나입니다. API의 작동 방식은 SOAP API, RPC API, Websocket API 등이 있는데, REST API는 현재 웹에서 가장 많이 사용되는 API입니다. 

    • REST API는 Representational State Transfer의 약자로, 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 방법을 의미합니다. 즉, URI를 통해서 자원을 지정하고, HTTP 메서드를 통해 해당 자원에 대해 어떤 행위를 할 것인지 표현합니다. 
      예를 들어 사용자를 CRUD하는 API를 만든다고 하면 아래와 같이 나타낼 수 있습니다.
      HTTP method URI
    CREATE POST /user
    READ GET /user/1
    UPDATE PUT /user/1
    DELETE DELETE /user/1

     

    • Rest의 개념을 만든, Roy T.Fielding은 이렇게 말했습니다. "HTTP에서 정의한 방식대로만 잘 쓴다면 REST는 딱히 할 말이 없다" Fielding이 말하는 REST API란, REST 아키텍쳐 스타일에 부합하는 API입니다. 이는 다음 6가지 항목으로 말할 수 있습니다.
      • Client-server: 클라이언트와 서버가 서로 독립적으로 분리되어 있어야 합니다.
      • Stateless: 요청에 대해서 클라이언트의 상태를 서버를 저장하지 않습니다.
        "치즈버거 주세요." "그리고 콜라 추가해주세요."(X)
        "치즈버거와 콜라 주세요." (O)
      • Cache: 클라이언트는 응답을 Cache(임시저장)할 수 있어야 합니다. 클라이언트가 Cache를 통해서 응답을 재사용할 수 있어야 하고, 이를 통해서 서버의 부하를 낮출 수 있습니다.
      • Uniform Interface(계층의 일관성): 인터페이스의 일관성을 지키고, 아키텍쳐를 단순화시켜 작은 단위로 분리하여 클라이언트-서버가 독립적으로 개선될 수 있어야 합니다. 인터페이스가 일관성을 갖는지는 다음 4가지로 판단할 수 있습니다.
        • 자원의 식별: 웹 기반의 REST에서는 리소스에 접근할 때, URI를 사용합니다.
          여기서 자원이란, 이름을 지닐 수 있는 모든 정보(개념적인 대상)을 말합니다. (문서, 이미지, 사람 등) Fielding은 자원은 객체이므로 상태가 변화 가능하므로 변하지 않는 식별자가 필요하다고 말합니다. 이 때, 그 식별자가 URI가 됩니다. 따라서 URI를 통해서 자원을 식별합니다. 예를 들어, /user/1이라는 URI로 user 데이터베이스에서 id가 1인 사용자를 식별할 수 있는 것이지요.
        • 표현(메시지)을 통한 자원의 조작: 리소스 조작을 위해서 데이터 전체를 전달하지 않고, 이를 메시지로 전달합니다.
          웹에서 데이터를 전달하는 방식은 HTML, XM, JSON, TEXT 등 다양합니다. 따라서 하나의 자원은 다양한 방식으로 표현이 가능합니다. 이때 데이터가 어떤 타입인지 알려주기 위해 HTTP 헤더에 content-type을 통해서 데이터 타입을 지정해줍니다.
        • 자기 서술적 메시지: 클라이언트와 서버를 오가는 메시지는 스스로에 대해 설명해야 합니다. 즉, 요청하는 데이터가 어떻게 처리되어져야하는지 충분한 데이터를 포현할 수 있어야 합니다.
          HTTP 기반의 REST에서는 HTTP 메서드와 헤더 정보, 그리고 URI에 포함되는 정보로 표현할 수 있습니다. 
          ex)
             GET: https://foo.co.kr/user/100 (사용자 정보 요청)
             POST: https://foo.co.kr/user (사용자 정보 생성)
             PUT: https://foo.co.kr/user (사용자 정보 생성 및 수정)
             DELETE: https://foo.co.kr/user/100 (사용자 정보 삭제)
        • HATEOAS(Hypermedia as the Engine of Application State): 하이퍼미디어를 통한 앱 상태 변경이 이루어져야 합니다. 일반적으로 프론트엔드와 백엔드 사이에서는 json 형태로 데이터가 오고가고, 프론트에서는 json을 html로 구성하며 html에서 앱 상태 변경이 가능합니다. 하지만 이때 REST API를 개발하려면 json에 URI를 포함해서 클라이언트에 전송해야 HATEOAS에 위배되지 않습니다. 즉, REST API를 개발할 때 단순히 클라이언트 요청에 대한 데이터만 응답해주는 것이 아니라 관련된 리소스에 대한 link 정보까지 같이 포함되어져야 합니다.
      • Layered System: 서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다양한 계층 형태로 구성이 가능해야 하며, 이를 통해 서버의 확장을 이룰 수 있어야 합니다.
      • Code-On-Demand: 자바스크립트 등 특정한 기능을 서버로부터 클라이언트가 전달받아 코드를 실행할 수 있어야 합니다. (최근 현업에서는 지키지 않는 곳이 대부분입니다.)

     

    반응형

    'Java > Spring' 카테고리의 다른 글

    [Spring Boot] API 개발 - response 내려주기  (0) 2023.01.23
    [Spring Boot] API 개발  (1) 2023.01.23
    [Spring MVC] Presentation Tier 구현  (0) 2023.01.12
    [Spring MVC] Business Tier 구현  (0) 2023.01.11
    [Spring MVC] Persistence Tier CRUD 구현  (0) 2023.01.11

    댓글